Hi guys, here we are going to learn about security model in salesforce.
It consists of 3 types
- Object level security
- Field level security
- Record level security
Object level security
It consists of 2 types.
- Permission sets.
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
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 ones defined by us. They can be deleted if there are no users assigned to that particular one.
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.
- By using “set field level security” button at field level.
- By using “view field accessibility” button at field level
- 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
- Role Hierarchy
- Sharing Rule
- Manual Sharing
- Apex Managed Sharing Rule
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 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 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
- Public Read.
- Read / Write.
- Read/Write & Transfer (Lead & Case object)-can transfer ownership
- Full Access (Campaign object)
To understand better about Organization Wide Default (OWD) let us see an example
|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.
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)
|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)
|Private||Private, PRO, PRW|
|Public Read only(PRO)||Private, PRO, PRW|
|Public Read Write(PRW)||Private, PRO, PRW|
OWD permissions are over riding(Public Read Only Access)
OWD permissions are over riding(Complete Access) (C/R/E/D)
It is used to display particular records to particular users, public groups, Roles.
- 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.