Sales representatives at Universal Containers need assistance from product managers when selling certain products. Product managers do not have access to opportunities, but need to gain access when they are assisting with a specific deal. How can a system administrator accomplish this?
A. Notify the product manager using opportunity update reminders.
B. Enable opportunity teams and allow users to add the product manager.
C. Use similar opportunities to show opportunities related to the product manager.
D. Enable account teams and allow users to add the product manager.
This is the question from the sample paper. I'm a newbie, i couldn't understand how the answer is B.
what does 'Enable opportunity teams' mean ? && how to 'allow users to add the product manager'
Opportunity Teams are a feature of salesforce. They allow you to modify the default sharing model (which might be set to private for Opportunities), and when you add users to an opportunity team, those users are given read and/or read/write access to that opportunity. I believe this is managed automatically behind the scenes by Salesforce via a sharing rule.
Related
The questions are related to snowflake account with organization/ orgadmin role enabled.
1.Is it possible to detach a snowflake account from a snowflake
organization?
a. If yes, will the removed account become a standalone(separate contract)
account? How does the billing work?
b. Will the account url change after detachment?
c. Procedure to achieve the above?
In an organization, are the background services charged on each account?
Can we clone a database across accounts within an organization?
What happens to the other accounts within an organization when the
primary account is deleted?
Can we get a cost comparison table between 2 standalone accounts and an
organization with 2
accounts?
After detachment can the account type/region/cloud provider be changed?
I have asked similar questions to snowflake support through support ticket system, But would like to get answers from the community too.
P.S If I get an answer from Snowflake, I will post it here!.
Yes - but you'd need to contact Snowflake support to do that.
a) not sure what you mean by standalone. All accounts are technically standalone. If you mean from a Snowflake contract, perspective, if you want them to be on a separate contract, you can do that. If you don't, it can remain on the same contract.
b) see (a).
c) if you are using the URL that uses ORG and account name, then yes, the URL will change. If you are using the URL that leverages an account locator and the deployment/region, then no. If won't and can't change.
d) Call Support
background services are always related to an account. An organization is just a way of grouping accounts.
No, but you can replicate data from one account to another account in Org. Cloning can only ever be done within a single account.
What happens to what? If this was related to cloning, then I don't think the question is valid. A replication would cease to replicate.
No costs for Organization so costs are the same per credit and per TB costs that you'd see on any account.
No, you can't move an account around. You'd need to create a new account, move your objects to the new account and then just remove your original account, if you wanted to move platform or region.
I've been tasked with setting up FreeIPA for my company. What we are looking to do is have multiple "admins" that can only manage and see the users that belong to their team. For example, we have three organizations in our company orgA, orgB, orgC. I want to appoint a manager from orgA to be able to create and edit users and groups that belong to orgA, but not be able to see anything that belongs to orgB or orgC. I found some documentation on the FreeIPA website, but it only appears to be a concept?
If anyone else has accomplished this or can confirm that it's just not possible, that would be helpful.
There is no support for multitenancy in FreeIPA and there is no plan to implement it. Separate organizations need their separate deployments.
I'm modelling a database schema that has the requirement of including multi-user account functionality:
A multiple user account enables multiple users to login to the same
account in order to do the job according to their permission level.
This means that it is possible to maintain a single account for your
entire marketing team. The account owner can add as many users as
he/she wants and limit what permissions each of them has. You can
choose a role for each user: account manager, marketing executive,
marketing assistant, etc… or create a customized permission.
At the moment I have one users table that stores the information of a generic user with the username and password etc. How would one implement a multi-user account functionality? Could an extra field be added to the users table that simply indicates the role? Would a separate table be required? I would like to use the principle of keeping this simple where possible but don't know how to approach this.
Each user is a assigned to one group, is that correct? In that case, the user table can have a groupid which is a foreign key to a user_group table which lists all the access roles that you have.
Now the group (groupid) may have a number of "access rights" of what they can (or cannot) do on the system, which can be defined by you. You can refer to this as a default set of access rights.
If you want to create a customized permission, it's best to read this SO question / the first two answers in the least:
Best Practice for Designing User Roles and Permission System?
In the second example which discusses bitwise operators (if you are doing this custom, without help of a framework as discussed in the first answer), this is interesting assuming you understand the concept. Effectively you are summing up the decimal integers but they are being compared in binary to know what roles are granted for a given user. You can use this concept to also define what access rights each preset groupid has for predefined roles.
For Oracle we have "Virtual Private Database". For SQL Server / Azure we have "Row Level Security". Whichever RDBMS you are using, check for similar feature. It is most efficient for this scenario.
I have a Role Hierarchy Setup with the following
CEO
-- Finance
----Department A Managers
------ Department A Users
----Department B Managers
------ Department B Users
I then only have 2 objects configured to Private
The problem is, we have certain people (Project Managers) that need to be able to view data from these two objects from different users in both Department A Users or Department B Users.
They should not be able to view data from either Department A Managers or Department B Managers.
Does anyone know how I can set this up to work with the above scenario ?
I've spent a lot of time on this and I am not sure the best approach.
Not sure if it possible, perhaps a trigger can be created (or workflow) to update the sharing rules of the record with the Project Manger? If that is the only solution then it might work.
Also I looked at creating a Sharing Rule but you can only share with a Role or Public Group, not an individual user.
Thank you
I think grouping and sharing is prob your best bet. So group dept.A&B users and group the PMs then share. Or you could add a field to your custom objects and share based on criteria, using the field as a flag, and share to the group of PMs. Maybe I've missed something.
I'm looking for a way to answer the question "what records does user XYZ have access to" - via the API or some feature that doesn't require the user to be logged in. Example: from an Administrative standpoint I want to see all my 250 users and the specific accounts that each has access to, including (if possible) the access level (r, r/w, c, d). Priority is read access though...what they "see".
Essentially I'm looking for a way to bulk export the UserRecordAccess "view" for a specific user which I specify, bypassing the 200 limit which requires record ID's to be provided.
This needs to be programmatic because I have to get it into a 3rd party compliance system.
This isn't possible. I ended up reverse engineering SF's security model, pulling everything from roles, to groups, to criteria based sharing out.