Salesforce Developer Data Security Record Access


// Salesforce - Developer - Data Security - Record Level (Overview):

By setting object and field-level access permissions in profiles and permission 
sets, you determine all of the objects and fields that any user of your app can 

The next step is to set permissions for the actual records themselves. 
To control data with greater precision, you can allow particular users to view 
an object (table), but then restrict the individual records (rows) they're 
allowed to see.

Record (row) access determines which individual records (rows) a particular 
user, profile, or permission set can view and edit in each object they have 
access to. Before configuring record access, it’s useful to answer the following 

1. Should your users have open access to every record, or just a subset?

2. If it's a subset, what rules should determine whether the user can 
   access them?

Let say you create a new profile called Recruiter to implement the object-level 
permissions required by recruiters. By restricting the power to delete 
recruiting-related objects, recruiters will never be able to delete these 
objects. However, the fact that you're granting recruiters permission to 
create, read, or edit recruiting objects does not necessarily mean that 
recruiters will be allowed to read or edit every recruiting object record. This 
is a consequence of two important concepts in the platform:

1. The permissions on a record are always evaluated according to a combination 
   of object-, field-, and record-level permissions.

2. When object- versus record-level permissions conflict, the most restrictive 
   settings win.

What this means is that even if you grant a profile create, read, and edit 
permissions on the recruiting objects, if the record-level permissions for an 
individual recruiting record prove to be more restrictive, those will be the 
rules that will define what a recruiter can access.

The platform provides the following record-level security and sharing tools:

1. Organization-wide defaults—specify the default level of access users have to 
   each others’ records.

2. Role hierarchies—allow you to ensure a manager will always have access to 
   the same records as his or her subordinates. Each role in the hierarchy 
   represents a level of data access that a user or group of users needs.

3. Sharing rules—enable you to make automatic exceptions to organization-wide 
   defaults for particular groups of users, to give them access to records they 
   don’t own or can’t normally see.

4. Manual sharing—allows record owners to give read and edit permissions to 
   users who might not have access to the record any other way.

These four methods are listed in order of increasing access:

Organization-wide defaults (most restricted)
  Role Hierarchy
    Sharing Rules
      Manual Sharing

You use organization-wide sharing settings to lock down your data to the most 
restrictive level, and then use the other record-level security tools to grant 
access to selected users, profiles, and permission sets, as required.

The visibility and access for any type of data is determined by the interaction 
of the above security controls, based on these key principles:

1. A user’s baseline permissions on any object are determined by the profile.

2. If the user has any permission sets assigned, these also set the baseline 
   permissions in conjunction with the profile.

3. Access to records a user does not own are set first by the organization-wide 

4. If the organization-wide defaults are anything less than Public Read/Write, 
   you can open access back up to certain roles using the role hierarchy.

5. You can further expand access, to additional groups of users, using sharing 

6. Finally, each record owner can manually share individual records with other 
   users by using the Share button on the record.
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License