The next level of security is object-level security. You can control who can view what objects in Salesforce. This is done through profiles and permission sets explained as follows:
Profiles: Profiles control what a user can or cannot do with objects and data, what they can do in the application, and whether they have access to certain page layouts, fields, and so on. Every user is given a profile. You can either choose from the standard profiles available in Salesforce or create a custom profile.
To see the profiles available in your org, click the gear icon on your Salesforce org home page and then search for Profiles in the quick find box.
Figure 1.17: Salesforce quick find box
Figure 1.18: Profiles in Salesforce
As you can see in the preceding image, there are a number of profiles available out of the box from Salesforce. You can also create custom profiles according to business needs. On the column named custom, those that have a checkmark on the custom column are custom profiles.
Figure 1.19: Permissions in a profile in Salesforce
Permission set: Permission sets grant additional access to users. Through permission sets, users are granted more access than what they have through their profiles. It is a collection of settings and permissions that give users additional access to various tools and functions. A user can have only one profile but they can be given more than one permission sets for different use cases.
To check the permission sets available in your Salesforce org, click the gear icon on your Salesforce org home page and then search for permission sets in the quick find box.
Figure 1.20: Permission sets in Salesforce
Record-level security refers to object records the users have access to on the basis of their profiles. As records are rows of data in Salesforce, record-level security essentially controls what data a user can view in Salesforce.
There are multiple ways access to records can be granted or restricted to users. By default, if a user has CRUD (Create, Read, Update, and Delete) permission on an object, they can perform CRUD operations on the record they create. Restrictions can be imposed to prevent users from taking action on records created by other users.
There are four different ways in Salesforce through which we can control record access. They are listed below in top-down order. Salesforce recommends setting the most restrictive access through org-wide defaults and then gradually increasing access through record security tools.
- Org-wide default: It specifies the default level of access that the user will have in that Salesforce org
Figure 1.21: Salesforce Org-wide default settings
There are four options to choose from for each object: private, public read-only, public read/write, and public read/write/transfer. The most restrictive is private, and the most access is given by public read/write/transfer. Access to records for child objects is determined by the access levels of the parent object.
- Role Hierarchies: Through role hierarchies, you can give access to users based on their role hierarchy. This means that managers have access to all records that are owned by their subordinates. Subordinates will not be able to access records that are owned by the managers.
- Sharing rules: If you want to give access to certain records to users, and if it is restricted by the two methods mentioned here, then you can use sharing rules. Sharing rules are like permission sets, except sharing rules give access to records, whereas sharing rules are for giving access to records. For example, if you want the marketing department to have access to those opportunity records where the lead is generated from email marketing, then you can create a sharing rule that will give the marketing team access to those records.
- Manual sharing: Manual sharing is used to give access to a user based on ad-hoc requirements. It is generally done by the owner of the record, but admins can also do it on their behalf.