This post extends on Prepare for the Salesforce Sharing and Visibility Exam – Understand the Salesforce Sharing Model – Post 2, in which I introduced you to the Salesforce Record Sharing model for internal users. In this post, I will walk you through what to do to create a record sharing model in your own Salesforce org.
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.
Setting Org-wide Defaults
Org-wide defaults (OWD) provide a default level of access for records owned by users. More importantly, they can be used to limit data access for each standard or custom object. You can set different levels for internal versus external users.
- Private is the most restrictive and means that only the record owner and users above them in the role hierarchy can view or edit records.
- Public read only allows all users to view records, but not edit them.
- Public read/write is the least restrictive level and means full access for all users.
- Public read/write/transfer is used only for case and lead records, since these types of records can be transferred to another owner.
For each object there is a “Controlled by parent” checkbox. As you might guess, this affects objects that are children. They will inherit the access level of the parent.
Every time that user attempts to access a record from a particular object, Salesforce will first check the OWD. If it is set as private or read/only, the system will look at the object’s sharing table and join the group membership table based on the ID of the user trying to access the record.
Depending on what is found, the least restrictive access will be granted. The access grant, or sharing row cause will be stored as a record in the sharing tables that I told you about in the last post. This is the record access calculation process.
Designing a Role Hierarchy
Role hierarchies provide data access for a group of users. It allows managers access to records owned by their employees. Essentially, record access is opened up vertically to users higher up in the hierarchy. By default, peers or other members assigned to the role will not have access to these records.
The role hierarchy is just one tool included in the Salesforce Sharing Model. The role hierarchy sits right in the middle. This means that baseline access, implicit sharing or org-wide defaults will override access provided by the role hierarchy.
When designing a role hierarchy, the following things should always be kept in mind:
- Your role hierarchy should NOT be a duplicate of your company org chart.
- Users should be grouped into access levels. Only users assigned to roles above them will have the same access as the record owner.
- Roles should only be created for permanent groups of users and not a group that is considered temporary because changes cause expensive sharing recalculations to take place.
- Orgs created prior to the Spring 21 release are limited to 500 roles.
Sharing Rules and Manual Sharing
It is important to realize that the entire Salesforce sharing model is model is built around record ownership. When a user creates a new record, they automatically become the record owner. Records can also be assigned to queues.
Sharing rules are created for objects, but you only do this if the OWD for that object is set to private or read-only. Otherwise, there is no need to create a sharing rule since everyone has access to that object. They open up object access for a select group of users.
When thinking about selecting a group of users, they can be assigned to a public group, which is not the same things as a queue. A public group consists of one or more users. These users can be individual users, or they can belong to a role or territory. Users that are part of a group cannot own a record, but they can be part of a sharing rule.
Queues on the other hand are generally used to manage ownership of objects such as leads, cases, and even custom objects. The record is owned by the queue and not any of the users assigned to the queue. However, queues are not used in sharing rules. Sharing rules are configured with public groups or roles.
Manual sharing happens when one user wants to share a record with another user. They can do this by clicking a button in the user interface. But keep in mind that manual sharing is only available for Accounts, Contacts, Cases, opportunities, leads and custom objects.
Only certain users can grant this kind of access. This includes, the:
- Record owner
- Users above the record owner in the role hierarchy
- Any user that has been granted full record access
Manual sharing is primarily used for special exceptions. That is why it sits above sharing rules in that upside down triangle you saw earlier.
Stay tuned for upcoming posts in this series and you may want to checkout the Salesforce Certified Sharing and Visibility Designer Skill Path on Pluralsight.
Can you explain “This means that baseline access, implicit sharing or org-wide defaults will override access provided by the role hierarchy.” I thought as you move up the upsidedown pyramid the access opens up like with sharing rules and manual sharing.
The most restrictive access is at the bottom and this will override anything higher up the triangle. So, any baseline access will override anything granted higher up. I realize this makes is slightly confusing and challenging to understand. Salesforce security is very complex and complicated. This is one of the hardest subjects to get, in my opinion. Whenever you are faced with a problem where a user cannot access something they (or you) thinks they should, it is probably an issue with security. Hope that helps.
But doesn’t sharing rules, manual sharing, and role hierarchy open up record access provided there is object access? So for instance if one restricts on OWD to private, then the other sharing tools can open that up provided there is object access?
It does open up the access to more users, but the base access is always considered first. So, even if you open up record access to a group of users for a specific object through the role hierarchy, that record access can always be overriden by the fact that a particular user does not have access to that object through their profile. That is the part that can get confusing. Also (as you stated) there is the OWD for an object to consider.