Record level Security Model In Salesforce

Greetings everyone, Today’s topic of discussion is the Record level Security Model In Salesforce. It’s the fortress that shields your Salesforce records, determining which users can access specific records within an object. With this robust model, you’re in command of who can view, edit, or delete records.

We can also control access settings for records.

To specify record-level security, we define organization-wide sharing settings, Role hierarchy, and create sharing rules.

Also, check this: Field Level Security Model in Salesforce

Key Highlights :

1. Profiles: Define broad access privileges based on user roles.
2. Permission Sets: Fine-tune access for specific users, extending or limiting their privileges.
3. Role Hierarchy: Establish a hierarchy that influences record visibility and accessibility.
4. Sharing Settings: Specify how records are shared among users.
5. Data Privacy: Maintain the confidentiality of sensitive information.
6. Regulatory Compliance: Ensure compliance with industry standards and regulations.
7. Business Logic: Protect records based on your organization’s unique processes.

Guardians of Data Integrity:

By delving into the intricacies of the Record-Level Security Model, you’re a sentinel of data integrity. Your understanding fortifies your organization’s data, ensuring it’s in the right hands and aligned with your business goals.

Explanations:

Record level Security Model consists of

• OWD
• Role Hierarchy
• Sharing Rule
• Manual Sharing
• Apex Managed Sharing Rule

Role Hierarchy:

Salesforce offers a user role hierarchy that you can use with sharing settings to determine the levels of access that users have to your Salesforce org’s data. Roles within the hierarchy affect access on key components such as records and reports.

Role

• Role controls the level of record access the user has.
• Helps extend the OWD settings for different objects.
• Sharing rules can be written to share records with particular role and subordinates.
• Defining the role of the user is not mandatory. 

Role defines what user can see depending on the hierarchy (Helps in defining data visibility)

OWD:

• OWD stands for Organization-Wide Default (OWD). Organization-wide default settings are baseline settings in Salesforce that specify which records can be accessed by which user and in which mode.
• Organization-wide default settings can be overridden using Sharing rules.
• We cannot uncheck grant access using the hierarchy for standard objects.
• If we uncheck grant access using hierarchy for the custom object than the user above the record owner will not be able to see record if OWD for an object is private.
• Although it’s easy to confuse permission sets and profiles with roles, they control two different things. Permission sets and profiles control a user’s object and field access permissions. Roles primarily control a user’s record-level access through role hierarchy and sharing rules.

There are 5 types of access level in OWD. They are

1. Private.
2. Public Read.
3. Read / Write.
4. Read/Write & Transfer (Lead & Case object)-can transfer ownership
5. Full Access (Campaign object)

To understand better about Organization-Wide Default (OWD) let us see an example

Profile	OWD	Outcome
CRED	Private	Only see contacts that he/she owns and on those records, he has got edit and delete permissions.
CR	Private	Only see contains that he/she owns and on those records, she DOES NOT have got edit and delete permissions.
CRED	Public  Read only	See all contacts but has EDIT/DELETE permissions only for records that he owns…for other records, he can only view and not edit/delete.
—	Public Read only	Nothing can be accessed
CRED	Public Read Write	Can create new records Can see/edit/delete all records.
CR	Public Read Write	Can create new records.Can view all records but no edit/delete options are available.

To check object level permission Go to Profiles.

• CRED means CREATE, READ, EDIT, DELETE.
• Standard object and custom object permissions are available in profiles.

Sharing Rules:

It provides extra permissions to public groups, Roles, Roles & subordinates.

Sharing rules are applied based on the criteria:

• Ownership-based Sharing Rule
• Criteria-based Sharing Rule

When setting up a sharing rule in Salesforce, one must decide whether their sharing rule is going to be “Owner-based” or “Criteria-based”. In other words, do you want the rule to be dependent on who owns the record in Salesforce or based on some other combination of data elements on the record.

OWD & sharing rules in the relations:

Master-Detail(Inheritance is possible)

Parent	Child
Private	Controlled by Parent(Private)
Public Read only(PRO)	Controlled by Parent(PRO)
Public Read Write(PRW)	Controlled by Parent(PRW)

Lookup Relationship(Inheritance is not supporting)

Parent	Child
Private	Private, PRO, PRW
Public Read only(PRO)	Private, PRO, PRW
Public Read Write(PRW)	Private, PRO, PRW

View All

OWD permissions are overriding (Public Read Only Access)

Modify All

OWD permissions are overriding(Complete Access) (C/R/E/D)

Manual Sharing:

It is used to display particular records to particular users, public groups, and Roles.

Note :

• If we want to share the record manually, then owd must be private or PRO.
• If we give OWD as a Public read-write, then the manual sharing button will not be enabled on the detail page of the record.
• If OWD is a public read-write transfer & we want to share the record manually, then we need to assign the permission set for the user, then give access as View all (or) modify all permission in permission set(obj) then assign to the user.

Apex Managed Sharing Rule:

• Apex managed sharing enables developers to programmatically manipulate sharing to support their application’s behavior through Apex or the SOAP API
• Apex managed sharing must use an Apex sharing reason. Apex sharing reasons are a way for developers to track why they shared a record with a user or group of users.
• When you use Apex managed sharing to share the custom object, only users with the “Modify All Data” permission can add or change the sharing on the custom object’s record, and the sharing access is maintained across record owner changes.

Example – If any object is private with org-wide default then we can extend the access to public read only or public read write with sharing rule.

Reference :

1. Salesforce Security