Security is an important aspect of any enterprise application. The ability of a platform to provide a facility to control the access of data among various users is key to adopting the platform. The Salesforce security model is robust, and proper understanding of the security features provided by the platform can help you design a better application from the security aspect. The aim of this chapter is to explain how an administrator can configure security settings and set a security model as per the business needs. We will start by explaining Organization-Wide Defaults (OWD) and then explain sharing rules configuration and role hierarchy. The end of the chapter will explain audit features provided by the platform; these features can help in tracking changes that have been made in the instance.
Before we dive deep and understand OWD in detail, it's important to recall the profile that provided us with the ability to perform Data Manipulation Language (DML) operations such as create, read, update, and delete (CRUD) access for the user. This chapter will discuss how we can control record-level access across users. OWD defines the base level security for an object across the organization. It is the default level of access as well. Let's first define the various types of OWD settings that can be configured for an object.
The following table summarizes the various values that can be set for OWD for an object:
Let's discuss what a role hierarchy is before we progress further. As we read in the preceding table, if the Grant Access Using Hierarchies checkbox is checked, then even if the Organization-Wide Defaults setting is set to private, the users above the role of the owner of the record still have access to edit and view the records. Hence, defining the role hierarchy for your business use case is a very important design consideration.
Consider a simple use case of a sales organization for my company named Administrator. The records owned by sales representatives must be accessible to the sales managers, COO, CFO, and CEO. The sales managers, CFO, and COO report to the CEO of the company, and hence, the records owned by them should still be accessible to the CEO of the company named Administrator.
In Salesforce, to set up this hierarchy, navigate to Setup | Administration Setup | Manage Users | Roles. The following screenshot shows a sample role hierarchy structure for sales organizations:
As shown in the preceding screenshot, you can use the Add Role button to add the necessary roles in the role hierarchy.
Role hierarchy will have meaning only if your organization has set the OWD setting as Private or Public Read Only. Public Read/Write or Full Access signifies that any user has access to edit and read records, and hence, hierarchy makes no sense here.
From the discussion so far, let's draw some conclusions that are clear at this stage:
- OWD is a base-level or default-level access, and setting this to Private will mean only owners have access to the records. Users above the record owner's role also have access to the records, provided the Grant Access Using Hierarchies setting is checked for objects. Again, it's important to note that for standard objects, we don't have a choice to uncheck the Grant Access Using Hierarchies option.
- If OWD is set to Public Read Only, it implies only record owners and users above the role hierarchy of record owners will have edit access to the records, while the rest of the users have read-only access.
- If OWD is set to Public Read/Write or Full Access, then all the users have access to edit and read the record and in the case of Full Access, even delete access to the records.
One has to navigate to Setup | Administration Setup | Security Controls | Sharing Settings in Salesforce to configure OWD settings for standard and custom objects; this opens the Sharing Settings wizard, as shown in the following screenshot:
As shown in the preceding screenshot, there are two columns: Default Internal Access and Default External Access. These types of options appear when external organization-wide default settings are enabled for the organizations. Let's define these in a tabular format:
|
Access |
Description |
|---|---|
|
Default Internal Access |
The internal access is for internal users and would exclude all users defined as external users. |
|
Default External Access |
External users include the following:
|
Note
In the older instances, when organization-wide default settings were not available, if your organization wanted Public Read Only or Public Read/Write access for internal users, but Private access for external users, one had to set the default access to Private and create a sharing rule to share records with all internal users. This method was heavier and degraded the performance of an organization with huge numbers of records.
With separate organization-wide defaults, one can set different sets of OWD for internal and external users.
Also, the Grant Access Using Hierarchies checkbox, which can be seen in the preceding screenshot, is editable only for custom objects. Once it is checked, the role hierarchy will be applicable for the OWD settings, as discussed earlier.
The following screenshot shows the User Visibility Settings window found in the Sharing Settings configuration page. These settings are available only in the newer instances of Salesforce.
The new organization can see their User Visibility Settings window in the OWD section. Once these settings are checked, the users can see each other's record irrespective of the organization-wide settings. In short, the organization-wide default settings don't apply, and user-visibility settings override them, providing extra access to the users.
At the profile level, we have to set CRUD access. Let's recall this by observing the following screenshot:
The Data Administration section, as shown in the previous screenshot, has the View All and Modify All settings. If the View All checkbox is checked for an object, it will imply that the user will have read access to the object records, irrespective of the OWD settings. Similarly, if the Modify All setting is checked, the user has read and edit access of the object records, irrespective of the OWD settings we discussed so far. So, these settings are powerful, and at the profile level, one has to be very careful while checking these settings, as this will override the OWD sharing settings for the profile.
The profile has the Modify All Data and View All Data permissions under the administrative settings checked. Once these settings are checked, the sharing settings are simply ignored for all objects. So, one has to be very careful. If these settings are checked, the user gets access to all records of all objects, irrespective of the sharing settings and OWD settings.