Record sharing in Salesforce works by an Admin configuring Salesforce to open up access, instead of creating restrictions (as is the case with other CRM applications). The Organisation Wide Default is where all starts, which are the Sharing Default Access Settings that come out-of-the-box.
Sharing Rules are one way to open up access to particular users in your org, one of many ways that can add confusion when planning record access and data sharing in your org; in this way, they are similar to role hierarchies, but can never be more strict than your Organisation Wide Default settings (as I mentioned before).
This post will cover what Sharing Rules are, how to set one up, and important considerations to ensure your data sharing remains secure, easy to manage, and follows best practice.
What are Sharing Rules?
“Use sharing rules to extend sharing access to users in public groups, roles, or territories. Sharing rules give particular users greater access by making automatic exceptions to your org-wide sharing settings.”
The above is taken from the Salesforce Security Guide (developer.salesforce.com/docs).
So you can create rules to open up access to records by:
- Who owns it
- Or, by variables of the record itself
You can create these and find the org-wide sharing settings by navigating to:
Set up → Security → Sharing Settings
When to Use a Sharing Rule (vs. the Role Hierarchy or Permission Sets)
You can think of Sharing Rules as extensions to the Role Hierarchy. If you need to open up access beyond the Role Hierarchy you have set up in your org, then Sharing Rules are here for you! This is especially useful when the sharing you want to do doesn’t follow the ‘frame’ of your hierarchy design.
Why not Profiles or Permission Sets? These two access configurations give access to functionality, ie. what a user can do, not data, ie. what a user can see.
How to Create a Sharing Rule
First revise the Organization-wide sharing defaults, which: “set the baseline access for your records. You can set the defaults separately for different objects.” (source: Help & Training – Sharing).
If you have communities and or portals you will also see a column called ‘External Access Levels’, that gives you the flexibility to have more restricted access to external users such as your customer community users than your internal service agents.
Then select the type of rule, by:
- Who owns it: for example, the Sales Team shares visibility of all accounts with each other so that they don’t pursue the same customer, or can work together towards a deal.
- Record criteria: for example, sharing all cases with a Type ‘Complaint’ with their escalations team.
Next step is to define who the rule is sharing with. Which can be either:
- A Public Group: Salesforce functionality used for assigning records or resources (such as reports) to it, which enables a 1-click way to open up access to a set of users within the group.
- A specific role,
- ‘Role and subordinates’, which includes all users in a role, and the roles below that role.
- Or, the same as above, but applying to portal users (that would access Salesforce Community).
Finally, you can either grant view/read access or view & edit.
It will take a few minutes to take effect, and that timing will depend on the number of records in your org and the complexity of the rules being processed. To process these changes efficiently, it may be queued and you will get an email notification when the process has been completed.
Considerations and Best Practice for Using Sharing Rules
- You can define up to 300 sharing rules for each object, including up to 50 criteria-based sharing rules (if they are available for that object).
- As a best practice, keep the number of ownership-based sharing rules to 100 per object, and keep the number of criteria-sharing rules to 50 per object.
- If multiple sharing rules give a user different levels of access to a record, the user gets the most permissive access level. Think back to what I said in the introduction, that Salesforce sharing is about opening up access – once it’s opened up, you cannot place restrictions on top of opened access.
- Sharing rules automatically grant additional access to related records. For example:
- Opportunity sharing rules give access to the account associated with the shared opportunity (if they do not already have access to it).
- Contact and case sharing rules provide the role or group members with access to the associated account as well.
- Beware of the dangerous permissions of ‘View All’ or ‘Modify All’ within profiles. These permissions although set up in profile or permissions set where you should be giving object access, yet are actually giving access to records, refrain from using them. Also remember that these permissions can be applied to object-level but as well to All Data.
- For a sharing rule based on owner or group membership, you can edit only the sharing access settings (for rules based on any other criteria, you can edit both the sharing access settings and criteria).
- You can’t include high-volume portal users in sharing rules because they don’t have roles, and can’t be in public groups.
- Once a sharing rule has been saved, you can’t change the ‘Share with’ field settings when you edit the sharing rule. So, an Admin would need to re-create the rule if they needed to change the ‘share with’ settings.
- When you delete a sharing rule, the sharing access created by that rule is automatically removed.
With all of these considerations in mind, another thing I like to highlight is about how open and transparent should you make a Salesforce org. Ultimately, as users (at least internal) in an organisation are there to work towards a common goal, being able to view a greater number of records can give additional context and intelligence that can be an enabler to support organisation success.
Summary
I hope this post has shed some light on Sharing Rules. Of course, there is plenty in Trailhead, including a project to Protect Your Data in Salesforce, which contains a section to create Sharing Rules. Give it a go and tell us how it went!
Comments: