Security and Access Control in Salesforce

Salesforce provides quite elaborated security features, as compared to the access controls provided by database management systems or file systems.
If Salesforce data validation when applied appropriately, make data more secure and data security more transparent to the general user. Key points for access
control are:

1. Who is accessing
2. What data is being accessed
3. How data is to be accessed

Let us take each component in detail:

1. Who is accessing: Doing the access is always determined by the user who in session. Instead of specifying permissions to Users individually, we can group into 3 categories for ease:

a. Profiles
b. Role hierarchies
c. Public groups

a. Profiles: Access to business objects, such as Accounts, Contacts, and Leads can be specified. Profile specify 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 give you following default profiles and vary as per the Edition of Salesforce:

1. System Administrator
2. Standard Platform User
3. Standard Platform One App User
4. Standard User
5. Partner User
6. High Volume Customer Portal User and Authenticated Website User
7. Customer Portal User
8. Customer Portal Manager
9. Solution Manager
10. Marketing User
11. Contract Manager
12. Read Only
13. Chatter Only User
14. Chatter Free User
15. Chatter Moderator User

Administrators can extend these by creating custom profiles if necessary.

b. Role hierarchies: It 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. Logically a role

hierarchy in Salesforce must match a company’s org chart, but it does not follow watertight compartments i.e. can be altered as per the business requirement. For e.g. if Company Secatriate requires access to all the company’s data, he can be assigned the CEO role, i.e, 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).

c. Public groups: Used for 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.

2. What data is being accessed: What secures the data. In databases and file systems, this is the table or file. The equivalent in Salesforce is the
business object. We can restrict access to following in Salesforce:

a. Object
b. Field
c. Record

a. Object: 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.

b. Field: 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.

c. Record: It controls access to instances of objects. Rows are the individual records for which Salesforce provide the access control. For eg: 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.


3. How data is to be accessed: 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. Users can manipulate data by CRUD operations:

a. Create
b. Retrieve
c. Update (Edit)
d. 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: 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.

The way records created by one user are shared with other users is determined by:
a. Organisation Wide Defaults/ Sharing mode
b. Role hierarchy
c. Sharing rules
d. Manual sharing


a. Organisation Wide Defaults/ Sharing mode: The sharing model is set for each object by the administrator, and it determines the organization-wide
defaults for object sharing:

1. Private (only viewable/editable by the owner and users above the owner in the role hierarchy)
2. Public Read Only (Only owner, and users above the role in the hierarchy, can edit those records)
3. Public Read/Write

OWD is used to restrict the access to data, in comparison with other modes which are used to open the access.

b. Role hierarchy: 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.

c. Sharing rules: 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:

1. Read Only
2. Read/Write

d. Manual Sharing: 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.

To conclude 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. 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.

Note: If object-level permissions conflict with record-level permissions, Salesforce applies the most restrictive settings.