March 8, 2021Design User Access to Data in Salesforce
Sometimes I create slides to visualize concepts just for a specific meeting or context and later think that this could be useful for a broader audience. I'm determined to share the results of my work more broadly wherever possible and put my blog to good use for that.
This is a representation of the different tools available in Salesforce to design user access to data. As this visualization is quite different from all the content about this topic that I've seen so far, I thought it's worthwile to put it out there:
A user has exactly one profile and one role, additionally they can be assigned to one or multiple territories and/or public groups.
A record on the other side has exactly one owner and has a bunch of field values (e.g. an account could have an "Industry" picklist, an opportunity has a "Stage" assigned, and so on).
The most basic method of data access is ownership - if you're the owner of a record, you have access to it. Yay! Building onto this is the Role Hierarchy, which basically enables you to give access to records to everyone above the owner using a hierarchical structure.
An alternative (or addition, if you want) to the Role Hierarchy are territories. Records (accounts, to be exact) are assigned to territories based on certain field values (e.g. all accounts from the "Financial Services" industry could be assigned to the "Financial Services" territory and/or all accounts with more than 1,000 employees could be assigned to the "Enterprise Customers" territory). You then assign users to those territories, which gives those users access to the accounts (and related data, based on further configuration) in the respective territories.
Probably the most flexible way to give users access to records is via Sharing Rules. As always, great power comes with great responsibility, which in this case means there are some things to consider when making extensive use of Sharing Rules, especially with regards to handling performance and managing complexity. Sharing rules can be bases either on record ownership or on field values and can grant access to roles, public groups or individual users.
All the tools describe above are about giving user access to specific records. There's one important precondition to that, which is also depicted in the diagram although it's a bit grayed out because it's a different scope: Before a user get's access to records, they need to have access to the object in general and specific fields on an object. So while record access for example determines which accounts you get access to, your Profile (as well as additional Permission Sets) needs to grant you access to the account object in general and determin which fields on the account object you may read and potentially edit.