The sharing model

One of the first steps when designing a new Salesforce CRM implementation is to set up data access using the sharing model engine. This specifies who can see what!

To understand how this works, have a look at the following diagram:

Salesforce sharing architecture

Profiles determine Object-Level Security (OLS) and Field-Level Security (FLS). They control which objects a user is allowed to access (right or write capabilities) and which fields are visible and editable. You can create a fine-grained view of what’s available for a specific object type.

Your implementation may require that the Sales team shouldn’t be able to see the account’s billing information. Using FLS, you can hide those fields from the sales representative profile. On the other hand, the service team should not be able to access quotes objects: remove any read access to the quote object on the service team profiles.

Permission Sets contains mostly the same attributes as profiles but they are usually added to specific users to provide additional permissions that their sole profile does not grant (it’s like giving more powers to selected users). This allows them to create a small set of profiles (that applies to most users, thus reducing the amount of time needed for profile maintenance) and apply permission exceptions to given users without the need to create a brand new dedicated profile.

Supposing you already know what page layouts are, while page layouts define which fields a user can see or write to in that specific view of the record, FLS is org-wide, which means that if a profile cannot access a specific field even though a layout is set to display it, it will never be accessed by that profile.

That’s why layouts are used to organize data rather than limit its access (for example, a sales user should read the contact fields on a given case with the Contact Request record type, even if he is not interested in reading those fields on the Payment Confirmation record type, but at the profile level the FLS on those fields are not changed).

After profile configuration, record-level access configuration comes next:

• The Organization-Wide Defaults (OWD) define how users have access to each other’s records: when you want to protect an object, you set up the most restrictive access type (for example, Private) and then use the other available tools to give wider access to specific subsets of users. Let’s say a specific profile has access to read and write on the case object: if OWD is set to Public Read Only, a user can read all the cases but won’t be able to update them unless they are the owner of the record or are allowed to due to the other sharing features.

The OWD is the only configuration that can restrict user access to a record. Remember that this concept is at the base of the Salesforce sharing model.

• Role hierarchy represents a hierarchic view of the company’s employee structure (such as an organization chart). This level of sharing defines how records are shared across the hierarchy (for example, sales managers can see all the records that are owned by their sales representatives).
• Sharing rules are exception rules that can give wider access to records or a group of users who shouldn’t actually see those records because of OWD and Role Hierarchy configurations.
• Sharing sets/groups are used to share records with Salesforce community users.
• Users can be given the power to share records they own with other users who don’t have access to them otherwise. This is called manual/Apex sharing, and although it’s not an automated configuration, it gives your users the needed flexibility to work with their team members.

Manual sharing is removed when the record’s owner changes or when that specific manual sharing doesn’t add more access than the default OWD access level.

• Use team sharing to grant access to specific records (for opportunity, account, and case objects only): the record’s owner (or users who are higher in the role hierarchy or administrators) can create a team granting read-only or read/write access to their team users to access the record. You can only have one team per object.

Developers can create this kind of sharing programmatically.

• Territory hierarchies is a feature that’s specific for accounts, opportunities, and their child records (records that have a master-child relation with them). You can provide access to records based on specific one-dimensional division (for example, business units, zip code, and country) using territory sharing rules, which are recalculated every time the record changes its territory-linked fields.
• Apex sharing is the most powerful and granular feature that can give your sharing needs the right way to control record access if the previous features are not enough or don’t apply to your sharing model. Developers can create algorithms to programmatically share objects with whichever users/groups they need to.

One final kind of sharing is implicit sharing, which is related to specifically standard objects and is a native feature that cannot be switched off. Parent implicit sharing means that if a user has access to opportunities, cases, or contacts, they also have access to the parent account. Child implicit sharing is the opposite; it gives users access to child objects (contacts, opportunities, and cases) to the owner of a given account: the administrator can set up read, write, or no access for child sharing in the role definition.

The following diagram summarizes the previous concepts:

Sharing model flow

Let’s dig deeper into each way we can grant access to records.