Episode-10: Salesforce Security Model

 

Security is always crucial to any organization which cannot be compromised at any level. Therefore understanding the security model in salesforce is very significant for the admin as well as for the developers.

The Salesforce Security model is basically classified into 3 levels:

1.Object level Security

2.Field level Security.

3.Record level Security.

Before diving into it we must also understand the organization level access to the users. As an admin, you can create the users and allow them to log in to the org from the set of IP ranges and log in hours you define for them.

By default, salesforce does not restrict the login hours or IP ranges for the user but you  as an admin can always configure it in order to increase the organization's security in the following ways:

• Can set up the range of IP addresses at the company level i.e users outside the range are sent an activation code for login to the org.
• Can set up the IP range at the profile level i.e those users outside this IP range will not be able to access.
• Can define the login hours at the profile level i.e if users try to access the org outside the login hours will deny access.

Object Level Security:

Objects are like tables in the database. Object-level security is managed by the profile and the permission sets. Let's understand them in detail.

Profile: 

Profile controls what the user can access in the salesforce which means it controls the accessibility of objects, fields, page layouts, record types, apps, tabs, etc, and also controls system settings.

Accessibility of objects means what users can do with the objects ie CRED permissions.

C stands for  CREATE

R stands for READ

E stands for EDIT

D stands for DELETE.

Each user is mandatory associated with the profile. There is a special profile of the system administrator who has the superpower to access everything in the salesforce. They have View All and Modify All access in addition to CRED access to the objects and fields. 

Permission Set:

Now the question which might come in your mind is Why do we need Permission Set if the user already has the profile? Let's try to answer this and understands the concept better.

Every user is assigned one profile that provides access to the specified functions that the type of user performs but what if some users need additional access to objects and settings and you don't want to grant that additional access to everyone else having the same profile. In that case, you can assign the permission set to that particular user who needs additional access without changing his profile.

For Example:

Let's say you create a  new profile name it Custom User Profile that has read, create, and edit access on the lead object. Now you want Tom who is having the Custom User Profile also to have delete access on the lead object but you don't want all other  Custom User Profile users to have delete access on leads. So it doesn't make any sense to change the profile for Tom alone. Instead, you create the permission set having delete access on the lead object and assign it to Tom who needs it.

A user can have only one profile but can have zero or multiple permission sets assigned to him.

Field-level Security

Fields are similar to columns in the tables.

Field level security determines which fields the user can see and which  CRED permissions the user has on the fields. It can grant or restrict the visibility to individual fields based on the user profile. 

Like Object Level Security, Field-level Security is managed by the profile and the permission sets.

Profiles give baseline access to the fields and in order to give additional access to the fields other than given by the profile, we use Permission sets.

Record level Security

Records are similar to rows that contain data in the table. Record level Security controls the visibility of the records.

Record level sharing is needed when we want to share the records to the users who do not own the records. The owner of the record is the user who has created the record and has CRED access on it.

The following are the types of Record Level Security:

1.Organization-Wide Default (also known as OWD)  determine the baseline access and permissions users have to the records they don't own.

Let's see the different options available for OWD:

• Private: The most restrictive setting is private as users cannot see records they do not own.
• Public Read-Only: users can view the records that they do not own but they cannot edit them or transfer the records.
• Public Read /Write: users can view and edit the records that they do not own.
• Public Read/Write/Transfer-it allows non-owners to view, edit, and change ownership. This option only applies to leads and cases.
• Controlled by Parent: It determines the access level of the child in the master-detail relationship as it is controlled by the parent. 

2.Role Hierarchy

Role Hierarchy is used to open up the access to records if OWD is set anything restrictive other than public Read /Write.

This is generally used in the scenario when the managers above in the role hierarchy want to access the same records as their subordinates.

This can be done by selecting Grant Access Using Hierarchies checkbox (on the Organization-wide sharing default edit page) for custom objects as it is by default selected for the standard object.

3.Sharing Rules

Role hierarchy allows us to open up the access of records vertically up in the role hierarchy pipeline of any org. But what if you want to share the records with the peers in your team or with the members of other teams then we use sharing rules to share the records horizontally. The sharing rules are used only when OWD is set anything restrictive other than public Read /Write.

• Owner Based Sharing Rules: It allows to share the records based on roles or roles and subordinates or the public groups.

For Example, We want to share the records of the users having a role as 'Sales Manager' with everyone having a role as ' XYZ Sales Manager'.

• Criteria Based Sharing Rules

It allows us to share the records based on the specified value in the field.

4. Manual Sharing

The record owners can also share individual records with other owners using the sharing button on the record detail page.

Manual sharing is needed only if OWD is set anything restrictive other than public Read /Write.

5. Apex Managed Sharing 

There are complex business requirements where the above record sharing rules will not work so in that case we need to write the apex code for sharing the records. We will learn about those scenarios in the next blog in detail.

Note: You can only open up the visibility of records using Role Hierarchy, Sharing Rules, or Manual Sharing or apex Sharing but you can not restrict the visibility using them more than  OWD sharing settings as OWD is the most restrictive sharing setting user should have.

Thanks for reading my blog. Stay tuned till then keep learning and keep growing. If you find it useful then like and share.😊