Security Model in Salesforce

Hi guys, here we are going to learn about security model in salesforce.

Security Model

It consists of 3 types

1. Object level security
2. Field level security
3. Record level security

Object level security

It consists of 2 types.

• Profile
• Permission sets.

Profile

A profile is a group/collection of settings and permissions that define what a user can do in Salesforce. 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”.

A profile can be assigned to many users, but a user can be assigned a single profile at a time.

Types of profiles in Salesforce

Standard profiles:

 By default, salesforce provides below standard profiles. We cannot delete standard ones.

Standard Profiles available in salesforce are

• Read Only
• Standard User
• Marketing User
• Contract Manager
• Solution Manager
• System Administrator

Each of these standard ones includes a default set of permissions for all of the standard objects available on the platform.

Custom Profiles

Custom ones defined by us. They can be deleted if there are no users assigned to that particular one.

Permission sets

The permission set is also very similar to profile. Whatever you can manage at profiles (Like Object permissions, Field Permissions, User permissions, Tab settings, App settings, Apex class permission, visualforce permission, the same you can manage here also. But the main difference between these two is that user can have only one profile and can have multiple permission sets at a time.

So we can define profiles to grant minimum permissions and settings that every type of user needs, then we can use permission set to grant additional access.

Field Level Security

Field-level security settings let you restrict users’ access to view and edit specific fields.

At object level we can give permission on what user can with salesforce record like user can read, create, edit, delete, view all & modify all. Object permissions we can give at object level. Now i want to restrict few sensitive fields form my users. I don’t want display these sensitive fields for all users. We can restrict fields by using field level security.

We can give read & edit permissions to the field. We can handle these filed level permissions in three ways.

1. By using “set field level security” button at field level.
2. By using “view field accessibility” button at field level
3. In profiles/permission sets we can handle field level permissions.

Note: In profiles you can find Field level security section on profile detail page. You cannot find Field permission on profile edit page.

Record Level Security

Record level security 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 user has.
• Helps extend the OWD settings for different objects.
• Sharing rules can be written to share records with particular role and subordinates.
• Defining role for 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 specify which records can be accessed by which user and in which mode.
• Organization Wide Default settings can be overridden using 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 got 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 recordsCan 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 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 over riding(Public Read Only Access)

Modify All

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

Manual Sharing

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

Note :

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