- Can you tell the difference between Profile and Roles?
Profiles are used for Object level access settings.
Roles are used for Record level access settings.
- What are permission sets?
Permission Sets are used to extend Profile permissions.
- Can you override profile permissions with permission sets(i have defined some permissions in profile,i am trying to use permission sets for the same object,can i override permissions for a particular object in the permission sets over to the profile?
No. Permission Sets are used only to extend the Profile permissions. It never overrides.
- I want to have read/write permission for User 1 and read only for User 2, how can you achieve?
Create a Permission Set with read/write and assign it to User 1.
- Can you tell difference between Profile, OWD or a Sharing Rule?
Profile: Profile is used for object level access. It is used to provide CRUD(Create, Read, Update and Delete) permission.
OWD: OWD is used for record level access for all the users across Organization. It is used to provide Public Read Only, Public Read/Write, Private, Public Read/Write/Transfer(Lead and Case Objects alone).
Sharing Rule: Sharing Rules is used to extend Role Hierarchy.
- What is the role hierarchy?
Role Hierarchy states that higher hierarchy person can see lower hierarchy person records.
- I have an OWD which is read only, how all can access my data and I want to give read write access for a particular record to them, how can i do that?
All users can just Read the record.
Create a Sharing Rule to give Read/Write access with "Based on criteria" Sharing Rules.
- What is the difference between role hierarchy and sharing rules?will both do the same permissions?
Role Hierarchy states that higher hierarchy person can see lower hierarchy person records.
Sharing Rule is used to extend Role Hierarchy
What are permission sets and how do they differ from profiles?
Permission sets and Profies are very similar. They both contain similar permissions that can be assigned to a user so that they can do things like run reports or CRUD accounts or read and edit fields.
Where Profiles and Permission Sets tell you whether a user can create an account, it doesn’t tell you which account they can read or edit. That’s where row level access like roles and public groups come in – if a user’s profile says they can read, create, edit accounts then their role and public groups tell you which accounts they can read and edit.
In this way, Roles/Public Groups and Profiles/Permission Sets work together to determine a user’s access to functionality and to records. If you have one but not the other, you won’t have access to a record – so if you have Read on Accounts on a Profile/Permission Set but not through Sharing with Roles/Public Groups/Ownership then you don’t have access and vice versa.
There are some times when one may override the other. For instance, you can have the Profile/Permission Set permission, Modify All Data or View All Data, in which case, we’ll ignore sharing and assume you have access to the record – but there are only a few exceptions to the rule that Profiles/Permission sets work hand-in-hand with Sharing Roles and Public Groups.
- When will you use profile and permission sets together?
- Difference between roles and profiles?
Roles are one of the ways you can control access to records. They also impact reports (e.g. “My Teams” filter). Roles come into play if your security model (OWDs) are set to private. A little more on Roles and how they impact security:
Profiles help determine record privileges. Assuming the User can see the record, Profiles determine what the User can do, view or edit on that record. Profiles control other system privileges as well (mass email, export data, etc)
Profiles control-
The objects the user can access
The fields of the object the user can access
The tabs the user can access
The apps the user can access
The page layout that is assigned to the user
The record types available to the user
Role control-
Record level access can be controlled by Role. Depending on your sharing settings, roles can control the level of visibility that users have into your organization’s data. Users at any given role level can view, edit, and report on all data owned by or shared with users below them in the hierarchy, unless your organization’s sharing model for an object specifies otherwise.
- 1. What are differences between Profiles and Permission sets?
What functinality is the same and where do they differ?
Is there some link that lists that?
Why Profiles use Visible & Read-Only and Permission sets use Read & Edit to achieve the same thing?
- Why were permissions sets introduced?
As I understand people had problem because each person could have only single Profile.
So instead of expanding Profile functionality to allow multiple profiles to be assigned to single person as needed, permission sets were invented that do just that.
Can permission sets completely replace profiles
(maybe not in current form but with addition of some extra functionality)?
Can Profiles completely replace Permissions sets if it is added that single person can have multiple profiles?
How hard would it be to fuse Profiles and Permission sets into single entity instead of having two different functionalities that do the same thing.
- What is sharing rule?
- How many ways we can share a record?
Role Hierarchy:
If we add a user to a role, the user is above in the role hierarchy will have read access.Setup -> manage users -> roles -> setup roles -> click on ‘add role’ -> provide name and save.
OWD:
Defines the base line setting for the organization.
Defines the level of access to the user can see the other user’s record OWD can be Private, Public Read Only, Public Read and Write. Setup -> Security Controls -> sharing settings -> Click on ‘Edit’
Manual Sharing:
Manual Sharing is sharing a single record to single user or group of users.We can see this button detail page of the record and this is visible only when OWD setting is private.
Criteria Based Sharing rules:
If we want to share records based on condition like share records to group of users Whose criteria are country is India.Setup -> security controls -> sharing settings -> select the object and provide name and Conditions and save
Apex sharing:
Share object is available for every object(For Account object share object is AccountShare ). If we want to share the records using apex we have to create a record to the share object.
(31). What are Organization Wide Defaults?
– Defines the baseline level of access to data records for all users in the Organization (not including records owned by the user or inherited via role hierarchy)
– Used to restrict access to data
Access levels:
-Private
-Public Read/Write
-Public Read/Write/Transfer
-Controlled by Parent
-Public Read Only
- Organization Wide Defaults
(32). What is a Role and Role Hierarchy?
Role:
– Controls the level of visibility that users have to an organization’s data
– A user may be associated to one role
Role Hierarchy:
– Controls data visibility
– Controls record roll up – forecasting and reporting
– Users inherit the special privileges of data owned by or shared with users below them in the hierarchy
– Not necessarily the company’s organization chart
Notes:
• If using Customizable Forecasting, there is a separate forecast role hierarchy.
• EE can create Account, Contact, Opportunity and Case Sharing Rules. PE can ONLY create Account and Contact Sharing Rules.
• Assuming no sharing rules have been created, users in the same role cannot access one another’s records.
Example: Org Wide Default settings for opportunities are private. Creating a role and adding two users to that role does not allow those users access to one another’s opportunities.
• “Grant Access Using Hierarchies” allows you to disable the default sharing access granted by your role and territory hierarchies. This option can be changed for custom objects that do not have their organization-wide default sharing setting set to Controlled by Parent.
(33). What is Access at the Role Level?
– Defined when creating a role
– Level of access to Opportunities associated to Accounts owned by the role
– Level of access to Contacts associated to Accounts owned by the Role
– Level of access to Cases associated to Accounts owned by the role
– Level of access options depend on OWD
Notes:
• You can create up to 500 roles for your organization
• Every user must be assigned to a role, or their data will not display in opportunity reports, forecast roll-ups, and other displays based on roles
• All users that require visibility to the entire organization should belong to the highest level in the hierarchy
• It is not necessary to create individual roles for each title at your company, rather you want to define a hierarchy of roles to control access of information entered by users in lower level roles
• When you change a user’s role, any relevant sharing rules are evaluated to add or remove access as necessary
(34). What is a Sharing Rule?
– Automated rules that grant access to groups of users
– Exceptions to Organization Wide Defaults
– Irrelevant for Public Read/Write organizations
– Levels of Access that can be granted
• Read Only
• Read/Write
Notes:
• Sharing rules should be used when a user or group of users needs access to records not granted them by either the role hierarchy setup or the organization wide default settings.
– Sharing rules open up access whereas organization wide defaults restrict access.
– You can use sharing rules to grant wider access to data. You cannot restrict access below your organization-wide default levels.
• Sharing rules apply to all new and existing records owned by the specified role or group members.
• Sharing rules apply to both active and inactive users.
• When you change the access levels for a sharing rule, all existing records are automatically updated to reflect the new access levels.
• When you delete a sharing rule, the sharing access created by that rule is automatically removed.
• When you transfer records from one user to another, the sharing rules are reevaluated to add or remove access to the transferred records as necessary.
• When you modify which users are in a group or role, the sharing rules are reevaluated to add or remove access as necessary.
• For contact, opportunity and case sharing rules, if the role or group members do not have access to the account associated with the shared contact, opportunity or case the rule automatically gives them access to view the account as well.
• Managers in the role hierarchy are automatically granted the same access that users below them in the hierarchy have from a sharing rule.
• You can edit the access levels for any sharing rule. You cannot change the specified groups or roles for the rule.
(35). Types of Sharing Rules in Salesforce and Explain it?
Account Sharing Rules:
– Based on who owns the account
– Set default sharing access for accounts and their associated cases, contacts, contracts, and opportunities
Contact Sharing Rules:
– Based on who owns the contact (must be associated with an account)
– Set default sharing access for individual contacts and their associated accounts
– Cannot use with: Territory Management and B2I (Person Account) enabled orgs
Opportunity Sharing Rules (EE/UE):
– Based on who owns the opportunity
– Set default sharing access for individual opportunities and their associated accounts
Case Sharing Rules (EE/UE):
– Based on who owns the case
– Set default sharing access for individual cases and associated accounts
Lead Sharing Rules (EE/UE):
– Based on who owns the lead
– Set default sharing access for individual leads
Custom Object Sharing Rules (EE/UE):
– Based on who owns the custom object
– Set default sharing access for individual custom object records
(36). Uses cases for Sharing Rules in salesforce?
– Organizations with organization-wide defaults of Public Read Only or Private can create sharing rules to give specific users access to data owned by other users.
– Cases Sharing Example: To use cases effectively, customer support users must have read access to accounts and contacts. You can create account sharing rules to give your customer support team access to accounts and contacts when working on cases.
– Account Sharing Example: The Western and Eastern Regional Directors need to see all of the accounts created by each others’ sales reps. You can create two public groups – one that includes the Western and Eastern Regional Director roles and one that includes the Western and Eastern Sales Rep roles. Then create an account sharing rule so that records owned by the Western and Eastern Sales Rep group are shared with the group containing the Western and Eastern Regional Director roles.
(37). Best Practices of Creating Contact Sharing Rules?
– Account Org-Wide Default must be set to at least “Public Read Only” in order to set the Contact Org-Wide Default to “Public Read/Write”.
– To share ALL contacts in the system with a group of users or a specific role, create a sharing rule that uses the “All Internal Users” (or “Entire Organization”) public group as the owned by option.
– Use “Roles and Subordinates” over “Roles” where possible to minimize the number of sharing rules.
(38). What is a Public Group?
– A grouping of:
• Users
• Public Groups (nesting)
• Roles
• Roles and Subordinates
– Mixture of any of these elements
– Used in Sharing Rules – for simplification (when more than a few roles need to be shared to)
– Also used when defining access to Folders and List Views
For example, if a new user is assigned a role that belongs to an existing public group, that user will be
automatically added to the public group
(39). What is Manual Sharing?
– Granting record access, one-off basis
– Owner, anyone above owner in role hierarchy and administrator can manually share records
– Available on Contacts, Leads, Cases, Accounts and Opportunity records and Custom Objects
– Like sharing rules, irrelevant for Public Read/Write organizations
(40). What is a Sales Team? (EE/UE)
– Used for collaborative selling
– Used for sharing as well as reporting purposes
– Ad hoc or may use Default Sales Team (defined for user)
– Default Sales Teams may be automatically added to a user’s opportunities
– Who can add a Sales Team?
• Owner
• Anyone above owner in role hierarchy
• Administrator
Adding Default Sales Team Members:
– Click Setup | My Personal Information | Personal Information
No comments:
Post a Comment