Data Security and Sharing Models in Salesforce

Salesforce data is stored in three key constructions: objects, fields, and records. Objects are similar to tables in databases. Fields are similar to columns of the table. Records are similar to rows of data inside the table. Salesforce uses object-level, field-level, and record-level security to secure access to the object, field, and individual records.

Object Level Security in Salesforce: There are two ways of setting object permissions:

1. Profiles
2. Permission Sets

Record Level Security in Salesforce: Record Level Security in Salesforce determines which individual records, users can view and edit in each object they have access to in their profile. Salesforce provides 4 ways to implement it:

1. Organization-Wide Default
2. Role Hierarchy
3. Sharing Rules
4. Manual Sharing

Field level access to define the Field Level Security

Field level security in salesforce controls whether a user or department can see, edit or delete the value for a particular field on an object. It can be accessed via the Object Definition Page> Fields and Relationships>Set field-level Security. Field Level Security can not be implemented on Standard fields(Read-Only) like CreatedBy, LastModifiedDate, etc.

Sharing model in Salesforce (declarative)

1. OWD vs Profile vs Permission set

OWD	Profile	Permission set
Organization-Wide Defaults settings specify the default level of access to records.	A profile is a set of settings and permissions provided to a specific group of users that determine the extent of their actions in salesforce.	A permission set is a collection of settings and permissions that extend users’ functional access without changing their profiles.
OWD settings give you a baseline level of access that can be set for each object separately.	Salesforce by default provides Standard Profiles. These profiles can’t be deleted or customized like System Admin, Standard Platform User, Standard User, etc.	Using permission sets we can provide access and not restrict access. It helps minimize the number of profiles to be created by temporarily adding and removing permissions to users without the need to change their entire profile.
For most objects, OWD settings can be set to Private or Public Read Only(default), and Public Read/Write rules.	We can therefore clone custom profiles from these standard profiles and customize the access settings as per the need. For a user to be added to a profile, its license should match the required license of that profile.	We can clone or create permission set assignments and assign them to users regardless of their profiles.
Additional OWD for specific objects. Public Read Write Transfer: Available for Leads and Cases. Public Full Access: Available for Campaigns. Controlled by Parent: Available for Contact and activities.	A profile controls “Object permissions, Field permissions, User permissions, Tab settings, App settings, Apex class access, Visualforce page access, Page layouts, Record Types, Login hours & Login IP ranges. 1 user = 1 Profile	Permission sets can manage similar like Object permissions, Field Permissions, User permissions, Tab settings, App settings, Apex class permission, visual force permission. But 1 user can have multiple permission sets at a time. 1 user = up to 1000 Permission sets
For example, you can set the OWD for Cases to Private if you only want users to view and edit the leads they own Case Records. Then, you can create Case sharing rules to extend access to particular users or groups.	Object permissions: CRUD/CRED access can be specified to the profile which defines their actions on different objects. Data administer setting: View All, Modify All access. We override the OWD setting for that object when we specify View all and Modify all access for the object. These all accesses can be specified per object at the time of Profile Setup.	If a permission isn’t enabled in a profile but is enabled in a permission set, users with that profile and permission set have the permission, i.e. Permission sets can override the profile access.
OWD governs Organization-wise access for the object.	Profile governs department wise access for that object.	Permission sets govern special authority for specific users.

The profile is all about access to the org, While roles are all about data visibility. Having a profile is mandatory for the user, while roles are not.

2. Roles Vs Sharing Rules and Manual Sharing

Roles	Sharing Rules	Manual Sharing
Unlike the profiles, Roles are optional. Roles control the level of visibility that users have onto the salesforce data.	While all security settings are static in nature, the Sharing rule is a selective sharing model that based on certain conditions provides dynamic sharing.	Manual sharing comes in place when we want to share specific records with a specific user.
Users at a given role level, can view, edit, and report on all data owned by or shared with users below them in the roles hierarchy. *Full access to the senior level even if it is set on Private*.	Types of Sharing Rule: Owner based(not used much) and criteria-based sharing rule. Access provided: Read-Only and Read/Write	Manual sharing lets record owners give read and edit permissions to users who might not have access to the record any other way. *Read/Write default access*.
One user can have multiple roles.	Use Case: -Dynamic sharing to a role or Public group -All old/new records are shared that meet the criteria.	Access remains until the access is invoked by the user. It can be set up via the sharing button on the record detail page in Classic. The button is absent in Lightning.
If the access is not found on a certain object, the object has disabled “Grant access using Hierarchies” under the security setting.	Limitations: -Can not share with a single user or profile. -Does not provide the right to delete. -Criteria changes=Access revoked	If the button is not found, either the button was not added to the page layout, or you are not logged as the owner.

IMPORTANT Case: If OWD for an object is given as “public read/write” while in profile level it is only “read access” then the user can’t create a record and neither edit a record. Why so?

The Answer is Simple – as we know that Profile is used for Object-level access. And OWD is used for record-level access. So, If we want to create or edit any record we must have Read / Write permision on that Object.

Profiles give users permission to each object and determine what a user can do to records within the object. In this case, we set Read access for Object and set Read / Write access for the record of that Object. So we have to give create and edit permission in the profile. If the profile has only ‘Read’ permission on the object, then the ‘Edit’ button will not be visible on the record and it is not possible to verify read/write access got via OWD. 

Apex sharing in salesforce

Using the with sharing, without sharing, and inherited sharing Keywords

With sharing	Without sharing	Inherited sharing
Apex code generally runs in the “System” mode meaning that through an Apex Class the current user could get access to records which he would not have access normally through the User Interface. With sharing keyword allows you to specify that the sharing rules for the current user are considered for the class.	Without Sharing is the exact opposite of “with sharing” and is the default if not specified. Using without sharing keywords a class ensures that the sharing rules for the current user are not enforced. It ensures the code to not fail because of hidden records.	Apex without a sharing declaration is insecure by default. inherited sharing declaration enables you to pass App Exchange Security Review and ensure that your privileged Apex code is not used in unexpected or insecure ways, where a specific sharing declaration is accidentally omitted.
To ensure that your Visualforce Pages or else wherever you use Apex Classes runs in the current user’s context, (i.e it fetches only information that the user generally has access through the User Interface) we use the “with sharing” keyword.	Implementation of with and without sharing : -Inner classes do not inherit the sharing setting from their container class. -Classes inherit this setting from a parent class when one class extends or implements another. -If the class is called by another class that has sharing enforced, then sharing is enforced for the called class.	If the class is used as the entry point to an Apex transaction (DML), an omitted sharing declaration runs as without sharing. However, inherited sharing ensures that the default is to run as with sharing. A class declared as inherited sharing runs as without sharing only when explicitly called from an already established without sharing context.

Additional Resources

Hope this article helps you with clear information go forth and bookmark it! Shoot your queries down and let’s resolve them together…