Architech Solutions

Access Control in Salesforce: An Overview

Kevin Laine | May 14, 2009

The features that Salesforce.com provides for controlling data access are quite elaborate compared to, say, the access controls provided by database management systems or file systems. Although data access controls in Salesforce share the same conceptual basis as those in other systems, Salesforce supports variations that, when applied appropriately, make data more secure and data security more transparent to the general user. The price of these security features is more planning on the part of the administrator.

Typically, access control is based on who is doing the accessing, what data is being accessed, and how the data is to be accessed, for example, for viewing, creation, or editing.

Who?

Who is doing the accessing is always determined by the user in session. For ease of administration, users can be grouped in various ways so that the administrator does not have to specify permissions for each user individually. The idea of grouping users is pretty common across access control systems, but Salesforce supports three different ways of grouping, all of which may apply in any particular case:

• Profiles
• Role hierarchies
• Public groups

Profiles specify access to business objects, such as Accounts, Contacts, and Leads. They also specify other things, such as which actions can be taken and which components will appear on the screen. Each user must be assigned a profile, and a user can have only one profile. Salesforce comes pre-configured with about half a dozen standard profiles, such as Standard User and System Administrator, and administrators can extend these by creating custom profiles if necessary.

Role hierarchies facilitate access rights that reflect the responsibility hierarchy in an organization. For example, a sales manager should be able to see the opportunities being pursued by the sales reps that report to her, but not necessarily the opportunities of reps that report to other sales managers. A role hierarchy in Salesforce may match a company’s org chart, but it is not required to. For example, if legal counsel requires access to all the company’s data, he can be assigned the CEO role, say, at the top of the hierarchy. Each user may be assigned only one role but, unlike profile assignment, role assignment is optional (though highly recommended).

Public groups support the arbitrary grouping of users for the purpose of specifying access rights. Public groups can contain individual users, roles with or without subordinates, and/or other public groups. A user could be a member of any number of public groups.

What?

The “what” of access control is the data to be secured. In databases and file systems, this is the table or file. The equivalent in Salesforce is the business object. However, as with the “who” of data access, Salesforce provides various ways to specify the “what” at various levels of precision:

• Object
• Field
• Record

At the object level, users are granted or denied access to all instances of specific types of business objects. This is the coarsest level of data access, and it is specified for profiles, rather than roles or public groups. For example, only users in the Marketing User profile have full access to Campaign objects.

Field-level access provides a finer level of control. Objects consist of fields, and field-level access can be used to restrict access to individual fields. For example, Salesforce restricts access to the Created By and Last Modified By fields in all objects, preventing users from arbitrarily setting these values. Field-level access, like object-level access, is granted or restricted for individual profiles.

Record-level access controls access to instances of objects. If you think of an object as a table in a database or a worksheet in an Excel file, with the object’s fields represented by columns, then the rows would be individual records, and Salesforce provides access control at this level also. A user may have access to Opportunity objects, for example, according to object-level permissions associated with her profile, but there may be record-level permissions that restrict which Opportunity records she can access.

How?

The “how” of data access is best thought of from two perspectives: the way users are permitted to manipulate data and the way records created by one user are shared with other users.

From the first perspective, the ways users are permitted to manipulate data are described by the typical CRUD operations:

• Create
• Retrieve
• Update (Edit)
• Delete

These operations are individually either enabled or disabled for each object for each profile, and they specify the way users associated with a profile can manipulate objects and their constituent fields. Viewing and editing individual fields can be further restricted with two field-level settings, Visible and Read-Only:

Note that field-level settings can only further restrict the access specified for the object; there is no way, for example, to make a field editable if Update is not enabled for the object.

From the second perspective, the way records created by one user are shared with other users is determined by the sharing model, role hierarchy, sharing rules, and manual sharing.

The sharing model is set for each object by the administrator, and it determines the organization-wide defaults for object sharing:

• Private (only viewable/editable by the owner and users above the owner in the role hierarchy)
• Public Read Only
• Public Read/Write

The sharing model is typically used to specify the most restricted level of sharing required. The other sharing mechanisms are used to open up access to specific groups of users.

The role hierarchy enables data sharing upward in the organization. By default, a users can access all the data owned by and shared with users directly below them in the role hierarchy. This sharing can be disabled for individual custom objects.

Sharing rules are set by the administrator, and they determine object access based on who owns the object and who accesses the object. The settings for sharing rules are similar to those for the sharing model:

• Read Only
• Read/Write

Note that Private is not among these settings. This is because sharing rules are meant to open up access, while the sharing model is meant to restrict access.

Manual sharing is similar to sharing rules, except it is done by users on their own data, and it must be specified on each individual record rather than at the object level.

Confused?

If all this seems more complicated than it needs to be, it may be that you’re thinking of only the most basic use cases. To meet the practical demands of securing and sharing data throughout an organization, both within and across reporting lines, flexibility is required. And flexibility leads to complexity.

Don’t confuse (as I initially did) the object-level access specs (CRUD) with the various record-sharing settings. Ultimately, it is the object-level settings that determine how a record can be manipulated. The sharing settings simply affect access. For example, if a user’s profile grants him update permission on an object, he will not be able to edit records of that type owned by other users unless read/write record-sharing has been granted. Conversely, if read/write sharing has been granted, a user whose profile does not specify update permission will not be able to edit records of that type.

Salesforce has implemented safeguards to ensure that users cannot inadvertently disable the application or make data inaccessible to all. For example, users can always access their own data. Record-sharing settings have no impact on users accessing records that they own. Also, permissions on standard profiles cannot be changed. Finally, if object-level permissions conflict with record-level permissions, Salesforce applies the most restrictive settings.

Filed under: Sales & Marketing