Any data access in Salesforce is determined by a layered security model. With each layer, data access is gradually opened up. Therefore, it is imperative that at the lowest level the sharing and security requirements are well understood in order to configure the security settings as appropriate. The layers of the Salesforce security model can be visualized as follows:
Figure 2.6 – A visual representation of the layers of the Salesforce security model
The layers that make up the security model, how they are configured, and their impacts are explained in this section.
The access that users have to each other’s records by default is specified in the Organization- Wide Defaults (OWDs) for a Salesforce instance. Essentially, OWDs lock data access down to the most restrictive level, and then the other sharing and data access tools (explained in the following sections) are used to gradually open up data access to your users. For example, setting a read-only account OWD will mean that users cannot edit accounts by default. If users require the ability to only edit accounts they own, grant edit and read access at the object level through the use of a profile or permission set, leaving the OWD set to read-only for accounts. There are separate OWDs for internal and external (through a Salesforce Community or otherwise) users. The premise of access is the same, but the external OWDs facilitate locking down to a more restrictive data access model by default. For example,
you may opt for all regular (sometimes referred to as internal) Salesforce users having read-only access to all accounts by default, with external users accessing Salesforce through a community having an OWD of private for account records so that those external users can only see account records they own. The values available to be set for OWDs are explained in the following subsections.
OWD values
There are several options available when setting OWDs in your Salesforce instance, and they all have an impact on how data access works for a given object or associated records/objects.
Private
Only the record owner, or those users higher than the record owner’s role in the role hierarchy can view, edit, and report on records of this object.
Public Read-Only
All users can see records of this object type, but only the record owner and those folks higher than the record owner’s role in the role hierarchy can view, edit, and report on records of this object.
Public Read/Write
All users can view, edit, and report on data held in records of this object.
Public Read/Write/Transfer
Only applicable to case and lead objects, all users can view, edit, transfer, and report on data held in lead or case records where this option is set.
Public Full Access
This is only applicableto the campaign object. All users can view, edit, delete, transfer, and report on data held in campaign records if this option is set.
Controlled by Parent
Users can perform actions on related records (such as edit or delete) based on access to the parent record. For example, if a custom object called Invoice has Account as its parent object, and Invoice’s OWD is set to Controlled by Parent, then a users access to Account automatically means they have access to the invoice record associated with the account record. If the user has edit permissions on an account, then they will automatically have edit access to the associated invoice record.
It Is Imperative That OWDs Are Correct
OWDs were until recently the only way to restrict user access to a record. Changing an OWD will have an impact throughout the Salesforce Org (not least on the time it will take to perform sharing re- calculations), resulting in users potentially being able to see more data than they should do. Therefore, it is crucial that a users data access is thoroughly understood before implementing OWDs. Since the release of Winter ’22, a feature called restriction rules facilitates restricting access to certain records to a select group of users. This is explained in further detail in the Restriction rules section. Restriction rules are used to restrict users and are not a substitute for a well-designed OWD strategy.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
