Salesforce provides a robust and flexible data security model to secure data at different levels. It also provides a sharing mechanism to open up access securely based on business need.
Organization level security
For your whole org, you can maintain a list of authorized users, set password policies, and limit logins to certain hours and locations.
Login IP Ranges – Login IP Ranges defines a set of IP ranges, so a user with that profile can only log in from that set of IP ranges. If the user tries to log in outside that range, the user would be simply kicked out. There is always confusion between trusted IP ranges and login IP ranges. The difference is, using trusted IP ranges, users can log in outside the trusted IP range with verification method, whereas with login IP range, there is no way to log in outside login IP range
.
Login Hours – It allows us to set login and log out time-based on the day for users with the profile. You can set time daily in a week.
With the help of Login hours we can specify the hours when users can log in to the organization based on the user profile.
If a user tries to login outside of these hours, they are denied access. when a user is denied access, they see the same error message which appears when the username or password is incorrect.
Object permissions specify the base-level access users have to create, read, edit, and delete records for each object. Object permissions let us hide whole tabs and objects from particular users, so that they don’t even know that type of data exists.
We can manage object permissions in permission sets and profiles.
Permission sets and profiles are collections of settings and permissions that determine what a user can do in the application.
A user’s profile determines the objects they can access and the things they can do with any object record (such as create, read, edit, or delete).
Permission sets are used to grant additional permissions and access settings to users.
Read : With this permission user can view object’s records.
Create : With this permission users can read and create records.
Edit : With this permission user can read and update records.
Delete : With this permission user Users can read, edit, and delete records.
View All : With this permission users can view all records associated with this object, regardless of sharing settings (Overrides sharing ).
Modify All : With this permission Users can read, edit, delete, transfer, and approve all records associated with the object, regardless of sharing settings (Overrides sharing). We will discuss this in detail in our next blog .
Profiles are a group of settings and permissions which define what a user can access in the application.
Profile is mandatory for every user in salesforce. You cannot have a user without a profile. Profile states the objects/field permissions and also other permissions with in the org.
Profile controls following –
Object permissions (create, delete,read, edit permissions)
Field permissions
Record type and Page layouts
Apps visibility and what users can do within a specific app
View and Edit Password Policies
Login hours can be defined
IP address permissions
Tab settings
Classes, VF pages permissions
Record access determines which individual records users can view and edit in each object they have access to in their profile.
The permissions on a record are always evaluated according to a combination of object-level, field-level, and record-level permissions.
There are 4 different mechanisms that control record-level sharing among different sets of users.
Organization-wide defaults
Role hierarchy
Sharing rules
Manual sharing and team sharing
Organization-wide defaults :
Objects permissions (Create, Read, Edit, Delete) control what users can do with records they own.
The Organization-wide default (OWD) defines the level of access each user has for records for a particular object. OWD provides the baseline-level access that the most restricted user should have.
We can use org-wide defaults to lock down our data, and then use the other record-level security and sharing tools (role hierarchies, sharing rules, and manual sharing) to open up the data to users who need it.
Org-wide sharing settings can be set separately for each type of object (Standard Objects and Custom).
Object permissions determine the baseline level of access for all the records in an object. Org-wide defaults modify those permissions for records a users doesn’t own.
Note :
Org-wide defaults can never grant users more access than they have through their object permission granted in the user profile.
Let’s understand the sharing models which implement the organization-wide default settings.
Public Read/Write:All users can view, edit, and report on all records.
Public Read Only:All users can view and report on records but not edit them. Only the owner, and users above that role in the hierarchy, can edit those records.
Private: Only the record owner, and users above that role in the hierarchy, can view, edit, and report on those records.
Controlled by Parent: A user can perform an action (such as view, edit, or delete) on a contact based on whether he or she can perform that same action on the record associated with it.
Public Read/Write Transfer: All users can view, edit, transfer, and report on all records. Only available for cases or leads.
Roles :
Roles helps to increase the data visibility that a particular user has, In other words Roles controls the level of record access user has. Data visibility can be increased by building role hierarchy. It is not mandatory that a user should have a role.
The same role can be given to multiple users and they may or may not have the same permissions.
Role Hierarchy :
Role hierarchy refers to a set of roles in an organization and the relationship between different roles. Role hierarchy opens up vertical-level access to records.
Role hierarchy allows the user sitting in higher level have access of records owned by users having role lower in hierarchy. It helps to extend the OWD settings for different objects. It describes how roles connect to each other.
Users at any role level can view, edit, and report on all data that’s owned by or shared with users below them in their role hierarchy, unless your org’s sharing model for an object specifies otherwise.
As we know Organisation wide default sets the default access for objects.
For example : OWD set as private it would mean that only the owner of the record can access the record. But with the help of roles the additional access can be granted to the users of these records to other users i.e users higher in role hierarchy would get the access of records owned by users lower in hierarchy.
Salesforce uses role hierarchy to automatically grant access to users by default. Role hierarchy allows the user sitting in higher level have access of records owned by users having role lower in hierarchy. It helps to extend the OWD settings for different objects.
We can specify whether users have access to the data owned by or shared with their subordinates in the hierarchy.
The Grant Access Using Hierarchies option is enabled for all objects, and it can only be changed for custom objects. We can not changed it for standard objects.
We can control record visibility using Sharing Rules.
Using sharing rules we can share a record with multiple users who are connected by horizontal hierarchy. With Sharing Rules we can extend sharing access to user, roles or territories. This enables us to make automatic exceptions to our org-wide sharing settings for selected sets of users.
If we have org-wide sharing defaults of Public Read Only or Private, we can open access back up for some users with sharing rules.
Components of Sharing Rules:–
Sharing rule has three components:
Share which Records
With which User
What kind of Access
1. Share which Records:-
A record can be shared based on the ownership of a record or meeting certain criteria. Criteria-based sharing rules determine what records to share based on field values other than ownership.
2. With which User:-
We can define groups of users by role, by territory, or by defining a public group. A public group can be created to simplify sharing rule creation. A public group can be a combination of individual users, roles, roles & subordinates,territories,territories and subordinates and other public groups that all have common functions.
3. What kind of Access:-
We can provide access based on the requirement. It can be Read-only or Read and write access.
Notes:
Sharing rules can never be stricter than Organization wide default and Role hierarchy settings. They are only used to extend the access.
Types of sharing rules :
Owner-Based Sharing Rules
Criteria-Based Sharing Rules
We can create sharing rules based on record owner and based on criteria.
Owner-Based Sharing Rules:
An owner-based sharing rule opens access to records owned by certain users. We can provide which user’s records to whom and provide the access to what level like read only or read/write.
For Example: A sharing rule can be used to grant read only access to records owned by users with the ‘North marketing role to the ‘south marketing role’.
Criteria-Based Sharing Rules:
A criteria-based sharing rule determines with whom to share records based on field values. If we want to share the records with specified groups or roles, then we can use criteria based rules.
The criteria can be created with object’s fields.
Note: We can’t use Apex to create a criteria-based sharing rule. And we can’t test criteria-based sharing using Apex.
Users can manually share records with other users using the sharing button.
We can use manual sharing to give specific other users access to certain types of records, including accounts, contacts, leads, users, and custom objects.
Manual sharing provide additional access beyond the organization-wide defaults and sharing rules.
Manual sharing is available:
To Manually share the record , the user must be either the owner of the record, above the owner in the role hierarchy, a user with full access or an administrator.
The sharing button will only display if appropriate. Ex – OWD setting for the object is private or public read only .
Records can be share with:
Users Roles Managers Groups Manager Subordinates GroupsRoles and SubordinatesTerritoriesTerritories and subordinatesPublic Groupmanager groups
At object level permission we can control whether a group of users can create, view, edit, or delete any records of that object. What if we want users to have access to an object, but limit their access to individual fields in that object.
Don’t worry we have Field-level security……
Field-level security settings or field permissions, control whether a user can see, edit, and delete the value for a particular field on an object. These are the settings that allow us to protect sensitive fields.
Field-level security controls the visibility of fields in any part of the app, including related lists, list views, reports, and search results.
Field settings can be applied either by modifying profiles or permission sets or from the Field Accessibility menu in Setup.
Field can be set to not visible or read-only based on profile.
How to restrict Field Access with a Profile ?
Let’s take an example, a Sales Manager probably wants to keep some of the fields accessible only to selected people in the company. We can restrict the fields for all other users.
Navigate to setup >> Profiles
Select the profile, In our case let’s select “Sales Manager” Profile.
