How to understand Salesforce Sharing rules

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.

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.

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.

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.

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.

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.

While these may seem to be the easiest approach, you can accidentally give more access than you initially intended if you over-use these.