access control in sales force

7/31/2019 Access Control in Sales Force

1/4

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 companys org

chart, but it is not required to. For example, if legal counsel requires access to all the

companys 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?
http://www.architech.ca/2009/05/access-control-in-salesforce-an-overview/http://www.architech.ca/2009/05/access-control-in-salesforce-an-overview/http://www.architech.ca/2009/05/access-control-in-salesforce-an-overview/


2/4

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 fromarbitrarily 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 objects 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:

Field Access Visible Read-Only

Read-only visibility X X

Editable X


3/4

(Invalid setting) X

Hidden

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 rolehierarchy)

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 youre 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.

Dont 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 users 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


4/4

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.

access control in sales force

Documents