Salesforce Data Security Model

-Salesforce Data Security model-

Salesforce provides a secure and flexible data security model to secure data at different levels.

Org Level Security

Object Level Security

Field Level Security

Record Level

It all start with Object, field and record.

Lets have a look at above terms.

Object- They are similar to database tables that store the information

Field- They are the column from that database table

Record - Records are similar to rows of data inside the table.

Salesforce also provides sharing model to open up and allow secure access to data based on business needs.

Layer 1: Object Level Security.

Object-level access can be managed through two configurations - Profiles and Permission Sets.

             Access given- Create, Read, Edit, Delete, View All, Modify All

Profiles

Assigning a user a profile is compulsory, as this is the place where you configure other things like page layout assignments or login IP restrictions. However, for object and field security setup, configure profiles for minimum access and use permission sets to add permissions.

Permission sets

Permission sets are more flexible. In contrast to profiles, you can add multiple permission sets to a given user. This gives you much more flexibility at the time of designing your security model, as functionality can be grouped in more granular ways. When only using profiles, you needed to group all the object and field permissions in a single profile, for instance for a concrete job role, as sales exec. With permission sets you can have different permission sets representing the different tasks that that a sales exec performs: manage leads, approve opportunities, etc. and add or remove smaller chunks of permissions to a user at any time.

Layer 2: Field-level Security

Access given- Read, Edit, Hidden

 Even if a user has access to objects, he/she still needs access to individual fields of each object. In Salesforce, profiles and permission sets also control field-level access.

An admin can provide read and write permissions for individual fields.  An admin can also set a field to hidden, completely hiding removing access to the field to from that user. When you hide a field with field-level security , the field won't be accessible through any entry points (for instance via API).

Layer 3: Record level Security

Record-level security is often referred to as the Salesforce sharing model, or just simply "record sharing" or "sharing".

Salesforce provides five ways to share records with others and access others records. You start by configuring org-wide defaults, to lock down your data to the most restrictive level. Then you use the other record-level security tools to grant additional access to selected users when needed.

1:- Organization-Wide Sharing Defaults

2:- Role Hierarchies

3:- Sharing Rules

• Ownership-based Sharing Rule

• Criteria-based Sharing Rule

4:- Manual Sharing

5:- Apex Managed Sharing

1:- Organization-Wide Sharing Defaults

In Salesforce, records have a field called "Ownerld" that points to a real user. Owners of records are usually people who created the record and have full CRUD (create, read, update, delete) access to it.

Organization-wide defaults (OWD) control the default behavior of how every record of a given object (for example, Accounts) is accessed by users who do not own the record.

2:- Role Hierarchies

Typically in an organization, different job roles have different record access requirements. Normally job roles are sorted in a hierarchical way: users with a higher role should have access to records to which users in lower roles have access.

Note that a role hierarchy rarely maps to an org chart. It really maps hierarchies of data access. Salesforce provides an easy way to share records with managers and represent a role hierarchy. To use this sharing rule, an admin must first add the user to a role and grant access.

3:- Sharing Rules

Hierarchy-based sharing only works for sharing upward and in a vertical direction. What if we want to share laterally? For example, what if we want to share records that a user owns with his/her peers in the same team? This is where sharing rules come in.

Sharing rules provides away to share records laterally and in an ad-hoc fashion via public groups.

Let's look into the details.

• Ownership-based Sharing Rule

Ownership-based sharing rules let admins share records based on role, role-and-subordinate, and public group ownership.

• Criteria-based Sharing Rule

Criteria-based sharing rules let users access records based on the value of a field in a record, irrespective of who owns the record.

4:- Manual Sharing

Manual sharing provides a mechanism to share individual records with others. This permission is accessed through the Sharing button on the record details page, and lets end-users share individual record with others.

Please Note: This is only available if the OWD is private or public read-only because otherwise (say public read/ write), you wouldn't need it.

5:- Apex Managed Sharing

There are occasions when you can't share records via UI or settings, but you need to write Apex code to do so.