Understanding Salesforce Sharing rules
What is Sharing in Salesforce?
Salesforce is a powerful platform that has revolutionized the way that businesses and organizations keep track of their clients and customers.
One useful feature in Salesforce is its ability to provide information that has been gathered by one individual so that it may be used by others within the organization. Administrators can set it up to enable sharing access to those in public groups and to those within various roles or who may operate in different territories.
These rules are designed to open sharing customer information to segments of your organization that may have not already had access.
Administrators can provide record-level access to any object within Salesforce. This can include standard objects such as account, contact, opportunity and case objects, as well as any number of custom objects which can be built on the fly.
Access to these objects can be granted based on who owns a record, or due to a hierarchy of existing roles, and a set of sharing rules that can be set up. Records can also be manually shared among users.
Beyond this, developers can make use of “Apex” managed sharing to programmatically grant additional access.
If one is familiar with access control lists (ACL) on other platforms, working with sharing objects in Salesforce is quite similar; the concept is essentially the same. If you are used to working with one, you should have little trouble adapting to sharing settings in Salesforce.
How to manage Sharing in Salesforce?
Source: Salesforce Sharing Rules
To be able to manage sharing, one must first have administrative level access. Administrators have full access to all objects within the system and can configure them to be accessible to multiple users.
Types of Sharing rules in Salesforce
Managed sharing refers to a description of the access provided based on who owns a record, the hierarchy of roles, and various sharing rules that can be applied.
There are four levels of access that can be granted to users:
- Private: Access is granted only to the record owner and those with access above their level in the role hierarchy
- Public Read Only: If this access is set, users can view records but cannot edit them. The only person who can change the record in this case is the owner of the record, or anyone higher in the role hierarchy
- Public Read/Write: All users with access to the record can read or edit the file, but cannot transfer the record unless they are the record owner (or above the owner’s level in the role hierarchy)
- Public Read/Write/Transfer: The users have the same access as in the previous mentioned rules, but also have the ability to transfer and report on all records with this designation.
The hierarchy of roles defines what level users have access to. Below is an example role hierarchy that one may setup for an organization:
Role details will look something like this:
The owner of a record is typically the person who created it. The owner of an object record has full access to all aspects of the record, including read, right, and updating functionality. Owners can also share records, transfer, or delete them.
The hierarchy of roles is typically setup from the administrative role. Some roles exist as subsets of other roles, which may share all or some of the rights of the ownership record, dependent on the types of sharing rules that are set up.
Those users who are in the hierarchy above the record owner are automatically provided full access to the record. For certain types of custom objects, this behavior can be overridden.
It is important to note that the hierarchy of roles is not maintained with records at the time of sharing. Hierarchy access is determined at runtime.
It is possible for administrators to be able to create a set of rules which specify which users or groups have access to certain kinds of records.
Rules can be set based on ownership of specific records but can also depend on other criteria. These rules cannot however be added to packages or used for sharing logic for external applications, such as those obtained through AppExchange.
The management of sharing rules must be handled through the interface; it will not work using the Apex-based controls.
Manual Sharing in Salesforce
One helpful feature that will allow users to manually share records with any other user, or with a group of users is manual sharing. End users can provide individualized access for individual selected records. It is important to understand that the only people who are permitted to manually share records are the record owners, or anyone with a superior level of access (those who exist on a higher rung in the role hierarchy).
Other users can be given individual access to various parts of a record, but cannot be given full access, by design. If you wish to provide users with the ability to share a record with others, they must be given the “modify all data” permission. If a record owner changes, then permissions to all other users is automatically revoked, unless organization wide sharing is already set by an administrator.
Apex Managed Sharing
For developers working with Salesforce, Apex managed sharing provides the option of programmatically sharing items using Apex code. To be able to manage a record using Apex, a user must be given the “modify all data” permission. If a record’s sharing permissions have been set, these permissions will be maintained if a record changes ownership.
If a trigger has been setup to change the ownership for a particular record, if a user is using the API, standard user interface, the standard visualforce controller, or if a class has been defined using the "with sharing" keyword, the user running the code must have read access for the new owner’s record.
Triggers that begin using a class that has not been defined with the “with sharing” keyword should run without the requirement of a user having specific access.
Best practices for using Sharing rules in Salesforce
Maintain control over number of rules
One can get as granular as necessary with sharing rules. In fact, it is possible to include up to 300 sharing rules per object. However, this does not mean that you should use each one. It is generally better to keep the number of ownership-based sharing rules to 100 per object, and criteria rules to 50, otherwise it can suffer a little in performance, and may be difficult to manage.
Keep track of your sharing rules
If you end up with too many rules, they can be difficult to manage whether you are correctly maintaining access. If there is more than one rule applied to an object for a user or role, Salesforce will provide the more permissive access, so it is advised that you keep it simple. It is important to note that once you have saved a sharing rule, you cannot change who you have set up with the “share with” rule without recreating the entire rule.
Be careful with “View All” or “Modify All”
While these may seem to be the easiest approach, you can accidentally give more access than you initially intended if you over-use these.