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”
- Controlled by Parent
- Private
- Public Read Only
- Public Read/Write
- Public Read/Write/Transfer
- 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:
Roles:
- C-Level & E-Level Management
- Sales Management
- Sales Reps
- Operations Management
- Operations Dispatchers
- 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:
- Security controls- does the user’s profile have access to this object?
If no, deny access. - Is Grant Access Using Hierarchies enabled for this object?
If No –> Step 3
If Yes –>
- 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)
- Grant permissions of any sharing rule specific to my role
- 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
- Lead
- Account
- Contact
- Opportunity
- Case
- Campaign
- Custom Objects
Build Sharing Rules
Security Controls –> Sharing Settings
Sharing rules can be established between:
- Public Groups
- Queues
- Roles
- 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:
