Salesforce Developer Data Security Record Access
salesforce-developer-data-security
// 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
access.
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
questions:
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
defaults.
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
rules.
6. Finally, each record owner can manually share individual records with other
users by using the Share button on the record.
page revision: 2, last edited: 14 Dec 2016 20:55