Specifying the object-level security access is the main function of profiles (although additional settings are present, such as login hours, IP ranges, and the like, that aren’t in the scope of this exam). By specifying Create, Read, Edit, and Delete access to specific objects, users access to those objects can
be further opened up beyond the OWDs already set in the organization. Field-level security is also set in profiles and permission sets, so it is here where Read or Edit access to specific fields is done.
Every user must have a profile assigned to them. Permission sets can be used to grant further selective
access to objects and other features through organization settings available in the permission set.
Managed packages typically use permission sets to allow assigned users access to the functionality offered by the managed package.
A Quick Word on View All and Modify All
View All and Modify All essentially allow users to be given blanket Read or Edit access across the organization for a given object. They effectively ignore sharing rules for a specific object. Therefore, if users are assigned a profile or permission set with View All set for accounts, they will have read access to every account. Similarly, Modify All against accounts gives edit access to any account in the organization. View All Data and Modify All Data permissions are set at the organization level, and sharing is effectively ignored to grant read or edit access to all objects and records in the organization to users that have this permission.
Much like the structure of an organization, the role hierarchy is used to determine data access for
groups of users and ensures that managers always have the same level of data access as their employees
(regardless of the OWDs in place for that object). Each level of the role hierarchy should align with a level of data access needed by a particular group of users. Role hierarchies therefore deviate slightly
from an organization chart as the system administrator will typically sit in a role toward the top of
the hierarchy. Depending on the licensing in place for your Salesforce org, external users may have roles assigned, and therefore they may be subordinates to one of the internal roles.
The role hierarchy provides a special provision for access to cases, contacts, and opportunities outside of the OWD setup. Roles determine a users access to cases, contacts, and opportunities, irrespective of which user is the owner of those records. For example, you can set the contact object access so that all users in a particular role have edit rights to all contact records associated with account records that they own, regardless of which users actually own the contact records.
Role Hierarchy Limits
Organizations are allowed 500 roles by default, which can be increased by Salesforce if required (but you should be questioning if this increase is required, or a more effective role hierarchy design will work better).
Just like when changing the OWD for a given object, changing a users role will incur a sharing recalculation, as Salesforce will need to re-evaluate to correct the users access to data, as necessary. Also, just because you have two people in the same role, access to each other’s data is not guaranteed (as this would depend on the rest of the sharing setup of the organization). Sharing rules can be used in this instance.
Role Hierarchy Best Practices
Keep to the following best practices when designing your role hierarchy: no more than 10 levels of branches, no more than 25,000 internal roles, and no more than 100,000 external roles.
The role hierarchy is a foundational aspect of the entire Salesforce sharing model, and therefore taking the time to get it right is crucial. No one wants a soup of sharing rules for users having correct data access because the role hierarchy isn’t designed properly!
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
