Home Sharing model in Salesforce

Sharing model in Salesforce:

Sharing Settings control the default access for each object across the organization. Sharing rules per object can grant access beyond the default Sharing Settings; they cannot restrict access.

Default Sharing Settings

See “Sharing Model Fields”

  1. Controlled by Parent
  2. Private
  3. Public Read Only
  4. Public Read/Write
  5. Public Read/Write/Transfer
  6. Public Full Access (campaigns only)

Grant Access Using Hierarchies is cannot be disabled for standard objects. When this setting is enabled, the role of the record owner determines visibility throughout the organization. Users in roles higher in the hierarchy will be always have full access (view/edit/delete) to all records owned by those lower in hierarchy.

If Grant Access Using Hierarchies is not enabled, all roles are treated equally regardless of hierarchy.

Describe the scope and capabilities of Organization-Wide Defaults

Organization-wide defaults control the level of access each user has to record they do not own. Let’s examine my example:


  1. C-Level & E-Level Management
  • Sales Management
  • Sales Reps
  1. Operations Management
  • Operations Dispatchers
  1. Customer Service Management
  • Customer Service Reps

Sharing Settings for Opportunity are set to “Private”. A Sharing Rule exists that grants Operations Dispatchers Read Access to Sales Reps’ opportunities. Here’s how this would play out. We’re looking at access to Sales Reps’ opportunities:

C-Level & E-Level Management Full Access (hierarchy)
Sales Management Full Access (hierarchy)
Sales Reps No Access
Operations Management Read Access (granted by hierarchy)
Operations Dispatcher Read Access (granted by sharing rule)
Customer Service Management No Access
Customer Service Reps No Access

Notice how even sharing rules are affected by Grant Access Using Hierarchies. Note: Group-based sharing rules do not propagate using hierarchies.

Explain how access is granted through the Role Hierarchy

When a user accesses a record they do not own, the following takes place:

  1. Security controls- does the user’s profile have access to this object?
    If no, deny access.
  2. Is Grant Access Using Hierarchies enabled for this object?
    If No –> Step 3
    If Yes –>
  1. Is this user’s role higher in the hierarchy than the role of the record’s owner?
    If Yes –> Provide full access
    If No –> Grant permissions of any sharing rule for users lower in the hierarchy (see above example)
  1. Grant permissions of any sharing rule specific to my role
  2. Grant permissions of default sharing settings

Grant the highest privileges of all of these steps combined.

Note: sharing rules only control access to the object. Field level accessibility is not

Set up Organization-Wide Defaults

Security Controls –> Sharing Settings

Describe the use of Roles

Roles are a principal element in sharing rules. Users should be grouped into roles based upon their need for access to data- how they fit into the role hierarchy. Creating a role for each title is not required. Roles are accessed throughout the application, and are particularly important for reporting. For instance, if you have two groups “Outside Sales” and “Inside Sales” you can run comparative reports to both roles.

Build a Role Hierarchy

Manage Users –> Roles

Roles report to another role. It is a one-to-many hierarchical relationship.

Assign Users to Roles

Manage Users –> Roles

Mass-transfer records from one user to another

Data Management –> Mass Transfer Records

Select the type of record to transfer. Enter the old user, new user, and set the filter criteria for records to transfer. It is essentially the s
ame as running a report but instead of getting results you transfer the record.

List the objects that may have Sharing Rules

  1. Lead
  2. Account
  3. Contact
  4. Opportunity
  5. Case
  6. Campaign
  7. Custom Objects

Build Sharing Rules

Security Controls –> Sharing Settings

Sharing rules can be established between:

  1. Public Groups
  2. Queues
  3. Roles
  4. Roles and Subordinates

Share records manually

Note: The sharing button will only appear when a record the Sharing Model for the object is either Private or Read Only. In my developer test account, no objects by default qualified.

Click on the record, click Sharing. Select the users/groups and access level to grant. Records are shared as such individually.

Describe the use cases of Public Groups and where to use them

Public Groups are created by administrators and can be used by everyone; they have the same basic functionality as private groups. A few uses include using a sharing rule (org-wide or record sharing), specify contact synchronization, and add multiple users to a Salesforce Content workspace.

Compare and contrast Sales with Account teams

Both are Enterprise+ (Enterprise and higher editions only; this includes developer).

Sales Teams are designed to share information and establish roles between different roles within the organization. For instance, a Sales Rep, CSR, and Account Executive are all working on the same account. The owner of the opportunity can create roles for each of the others and provide write access to the opportunity:

Leave a Comment