Welcome back to the second post for this series. In this post you will be introduced to the Salesforce Record Sharing Model for internal users. This will involve sharing Salesforce data across users, groups and roles.
In this series, I will be sharing highlights from courses that are part of the Salesforce Certified Sharing and Visibility Designer Skill Path on Pluralsight. The skill path is designed to help anyone trying to pursue the Salesforce Sharing and Visibility Designer certification.
Diagnosing User Access Issues
Most Salesforce Administrators will eventually be asked why some user cannot access certain data. In situations such as these, it is helpful to refer to a diagram such as the one below.
The Salesforce sharing model can be imagined as an upside down triangle. Tools at the top of the triangle provide the widest level of access to the greatest number of users. Tools located at the bottom can be used more precisely to grant certain kinds of access to the least number of users.
When trying to figure out user access problems, you would start at the bottom. In other words, baseline access should be the first thing you look at, followed by implicit sharing and so on. Keep going up the triangle until you determine what the problem is.
| Sharing Tool | Description |
|---|---|
| Baseline Access | Involves a combination of a profile permissions along with permission sets. |
| Implicit Sharing | Salesforce’s built-in sharing behavior between account and child records (contacts, cases and opportunities) |
| Org-wide Defaults (OWD’s) | Determines an objects’ default access level and is the only way to limit record level access. |
| Role Hierarchy | Expands data access vertically. Allows managers to access records owned by the users they manage. |
| Sharing Rules | Define criteria for sharing access with specific users or users in public groups/roles |
| Manual Sharing | Typically used for special circumstances, users can intentionally grant record access to a user that would not normally have access. |
| Team Access | Used to grant access to teams, which are groups of users that work together on objects like accounts, opportunities or cases. |
| Territory Hierarchy Access | Used to manage and grant account access to users assigned to sales territories. |
I am not going to lie to you, the Salesforce record sharing model is complex. But don’t be overwhelmed because throughout this series, I will be introducing you to all of these tools.
Working with Access Grants
Access grants are what Salesforce uses to determine who sees what data. The process of determining this all starts with an object sharing table. Object Sharing tables are completely separate from the object table itself where all the Salesforce data lives, such as the information about an account lives.
Sharing tables will store information about the grant (or sharing type) such as whether it is explicit or implicit. Implicit grants happen when there are children records associated with a parent.
For instance, accounts and contacts are designed with this kind of relationship. Contacts are considered children of a parent account and understandably users that can access a contact can also access the account.
Implicit grants will override explicit grants, which happen when a record is shared with manual sharing or sharing rules. So it is important to always keep implicit grants, or implicit sharing in the back of your mind. If you ever have a situation where you cannot figure out why a user is accessing a record, consider implicit sharing.
If you ever have a situation where a user is accessing a record you think they should not have access to, consider implicit sharing.
Object sharing tables are created automatically and follow a very specific naming pattern. For example, when the object record table is named Account, the sharing table will be named AccountShare. And the thing that ties these two tables together is the owner of the record. When dealing with a custom object such as one named myCustomObject, the sharing table will have the object name followed by two underscores and the word Share.
Determining what values go into a sharing table occurs when record access is calculated. This is a separate process from when a user attempts to access the actual record in the user interface or with an API. This process only happens during a configuration change, such as creating a new custom object. And you should know that It is a very complicated resource intensive process known as sharing recalculation.
Things are done this way in order to improve record access performance. If all this checking was done in real time, the system would not perform well at all and users would be very unhappy.
Record access calculations can happen when changes are made to:
- Group membership
- Role hierarchies
- Territory hierarchies
- Kicked off manually by an Administrator
It is important to realize that record access calculations can act like a ripple effect in a Salesforce org. For this reason, large orgs should be especially careful when kicking this off or making any changes that might trigger it. The process could negatively impact the orgs performance.
Since this is such a HUGE topic, I will not be covering everything in this one post. Stay tuned for the next post where I will be covering more.
saramorgan.net 