Access and Sharing Explained
I have drafted an overview of access rights to objects and records. If you have any questions, feedback or corrections, please share them and I will update this overview.
Two Rules for Determining Access Rights
Determining a user’s access rights involves a two-step process:
- Object Access. First, determine whether the user has access to the object. If so:
- What types of access does the user have: read, edit, create or delete.
- What level of access does the user have to each object field: none, read or edit? A user with read-only access to a given object can never edit any of the object’s fields, regardless of any field-level access they may have been granted.
- Record Access. Second, assuming the user has any type of object access, determine whether the user has access to a specific record. A few restrictions, which cannot be overridden or bypassed:
- If a user does not have any access rights to an object, the user will not have any rights to any record of that object.
- If a user does have access rights to an object, those rights limit what a user can do with every record of that object, regardless of how record access is derived. A user with read-only access to an object who owns a record of that object will be limited to read-only access to that record, notwithstanding their ownership.
- With a few exceptions note below, a user will have the same CRED rights to every record of an object and the same rights to every field of every record. There might be situations where a user with edit rights or above to an object may be limited to read-only rights to a specific record.
Master-Detail Relationships
In a master-detail relationship, the configuration of object access rights can diverge between the parent and child. A user could have edit rights to the child object and read-only access to the parent object, or edit rights to the parent object and no rights to the child object..
However, access to a child record is always inherited from and matches the user’s access to the parent record, subject to the user’s rights to the child object. This covers both whether a user has access to a child record and what types of rights the user has to the child record, as the user’s rights to the child record will be limited to its rights the parent record.
Understanding the rules described above will help when configuring access rights.
The next two sections explains how a user can be granted object access, how the user can be granted record access, and the types of access the user will have to each.
How to Grant Object Access
There are only two mechanisms that can be used to grant a user access to an object:
- Profiles. Every user must be associated with a profile. A profile can be configured to grant access to any type of object, with these options: Read, Edit, Create or Delete, View All and Modify All. In addition, via the profile, different access rights can be granted to every field of the object: none, read or edit. Note that a new “View All Fields” setting has been added to make it easy to grant a profile the ability to view all fields with one checkbox, including future fields.
- Permission Sets. For object access purposes, permission sets can be configured exactly the same way as profiles, with the same settings. A permission set with object access can be assigned to a user to increase (not decrease or restrict) the user’s access to an object, access the user likely had not obtained via their profile.
How to Grant Record Access
Before continuing, let me reiterate one the restrictions on record access noted above, because Salesforce administrators may believe that record access is sufficient: If a user does not have any access rights to an object, the user will not have any rights to any record of that object.
Understanding and configuring record access is much more complicated than object access. As a general rule, each method of granting record access can be used only to increase which records a user can access or the types of access the user has, not to reduce access.
Super Powers
These two mechanisms for granting record access are what I think of as granting a user super powers:
- Via a profile or permission set, a user can be granted System-Wide View All Data or Modify All Data rights, found in the System Permissions section. If so, that would give the user access to all records of all objects, either read-only or edit/full.
- As noted above, via a profile or permission set, a user can be granted View All or Modify All rights to an object, which would give the user access to all records of that object, either read-only or edit/full.
Before continuing, let me reiterate another restriction noted above: If a user does have access rights to an object, those rights limit what a user can do with every record of that object. For example, a user who has View All rights to an object via profile/permission sets can never edit any record of that object.
Typical Methods for Granting Record Access
- Record Ownership. The first method by which a user obtains access to a record is through record ownership. Typically, ownership would be gratned if the object was created by the user, but ownership can also be transferred to the user later by another user with sufficient rights. (Note that the owner of a record can typically transfer ownership to another user, which is one way that a user may have more access rights to a specific record than other users with the same access to that object.)
- Organization-Wide Defaults. The next method for granting record access is using Organization-Wide Defaults (OWD) to configure either Public Read-Only or Public Read/Write defaults to an object. In that case, then every internal user (and external user, if so configured) would have read-only or edit rights to every record of that object. These OWD defaults are considered the baseline for granting access to records a user does not own.
- Role Hierarchy. Granting access via the role hierarchy is enabled for each object from the OWD setup page. (Role hierarchy is enabled by default for all standard objects.) If role hierarchy is enabled for an object, a user who is higher in the role hierarchy has access to every record of that object that everyone lower in the hierarchy either owns or which has been shared directly to them. However, the record access rights the more senior user will have is governed by their object access rights. Therefore, a junior user may have edit rights to the record but the senior user, with a different profile, may be limited to read-only rights. On the other hand, if the senior user has edit rights to the object and the junior user has read-only rights, the senior user can edit the records they gain access to via the role hierarchy.
- Sharing Rules. These rules are defined either by a record’s current owner or by record criteria and the rules identify which users or category of users will be granted access. Unlike role hierarchy, sharing rules can be limited to read-only access or can grant read/write access. Remember, there is no bootstrapping: a user whose profile grants them read-only access to an object will not obtain edit rights to a record they gain access to via a Read/Write sharing rule. On the other hand, a read-only sharing rule will act as a ceiling and limit a user to viewing a record even if the user has edit rights to the object via their profile.
- Manual Sharing. Other than how access is granted – one record at a time and manually – the configuration and impact of manually sharing a record works identically to how sharing rules work. A record can be manually shared with either read-only access or read/write access.
- Manual sharing for an entire org must be configured on the OWD page. Manual sharing is not available for an object if the OWD default for that object is Public Read/Write. Finally, Manual Sharing must be enabled for each object but is typically enabled by default for all objects.
- Only certain users can manually share a record, such as a system administrator, current record owner, a user above the owner if role hierarchy applies and users granted “full access” to a record via another mechanism. Manually sharing of a record can be revoked and is impacted if record ownership changes.
- Team Access. Teams can be created for accounts, opportunities and cases. If a user is added to a record team, the user will gain access to the record. (The mechanism is slightly different for case teams.) The type of access the team member is granted can be read-only or read/write, depending on how their team membership is configured. The user’s team access will act as a ceiling on their access to the record. A team member with read-only team access who has edit rights to the object via a profile will be limited to read-only access. Similarly, a team member with read-write team access who has read-only rights to the object via a profile will be limited to read-only access, because their object access acts as a ceiling.
