Organization-Wide Defaults (OWD) in salesforce

Salesforce allows us to set a baseline for a restricted user. It defines what the user should access, and what he should not. This baseline is also referred to as Organization-Wide Default or OWD. By enforcing the baseline, OWD restricts user access. In that case, access can be granted through some other modes, such as rules sharing, role hierarchy, etc. We can also say that OWD specifies the default level access for users in the org. The permissions set on the object determine the default level of access for the records associated with that object. OWD modifies the permissions on the object, for those records which are not owned by any user. The shared setting can be set org-wide specifically for each type of the object.  However, an important point to note here is that the OWD cannot increase the level of access for the user, from what they have from the object permission.

Levels of Access

There are four levels of access:

  • Public Read/Write/Transfer: This is only available for two specific objects, leads, and users.
  • Public Read/Write: All users can view, edit, and report on all records. However, this is possible only if they have the object's permission.
  • Public Read/Only: In this kind of access, all the users can view and report on records, but can’t edit them. Only the owner, and other users who are assigned with a role in the hierarchy, will have permission to edit them.
  • Private: in this kind of access, except the record owner, and users above that role in the hierarchy, no one else can view, edit, and report on those records.

Determining the OWD for the ORG

This is a key decision-making exercise, and to determine the OWD, you need to consider certain factors.

  • First, determine who is the user of the concerned object or the object in question (where OWD will be applicable).
  • Any instance of this object should be restricted from a certain user or group of users, for viewing.
  • Any instance of this object should be restricted from a certain user or group of users, for editing.

We can consider this as a flow diagram like we generally implement for decision making. We can develop a flow diagram based on the factors mentioned. A probable flow diagram is shown below.

 

 

How to setup OWD in Salesforce

  1. Login to Salesforce, and then go to setup.
  2. Go to the Quick Find box, and then look for “Sharing Settings”.
  3. Click on the edit option, in the OWD area. You will find the standard objects listed on this page. Beside every object, you will find a checkbox with the option “Grant Access Using Hierarchies”. This will disable the default access, controlled by the parent.
  4. Under the default access column, you can set the OWD for each of the objects. You can set any of the four levels of access, that have been described in the last section.

Exceptions to OWD

Exceptions to OWD can be implemented with the help of the sharing rules. Sharing rules can extend access to users in roles, public groups, or territories. It enables greater access by implementing automatic exceptions to OWD settings. Sharing rules can override the OWD settings, by enabling a greater level of access to specified users. The sharing rule can be based on any criteria such as record ownership. You can specify which records can be shared, and which cannot be. You can specify, who can have access to the record. It could be a user or a group. Salesforce allows to create up to 300 sharing rules for an object. Some of the common types of sharing rules created for exceptions to OWD are:

  • Account Sharing Rules
  • Account Territory Sharing Rules
  • Asset Sharing Rules
  • Campaign Sharing Rules
  • Case Sharing Rules
  • Contact Sharing Rules
  • Custom Object Sharing Rules
  • Data Privacy Sharing Rules
  • Knowledge Article Sharing Rules
  • Flow Interview Sharing Rules
  • Lead Sharing Rules
  • Location Sharing Rules
  • Opportunity Sharing Rules
  • Order Sharing Rules
  • Product Item Sharing Rules
  • Product Request Sharing Rules
  • Product Transfer Sharing Rules
  • Service Contract Sharing Rules
  • User Sharing Rules
  • Work Order Sharing Rules
  • Work Type Sharing Rules