After studying this topic, you should be able to:

Identify the appropriate security controls for various

user request scenarios

Describe how access to objects can be defined in

Salesforce

Explain the different options available for giving users

access to records, including organization-wide defaults,
role hierarchy, sharing rules, and manual sharing

Explain the use of field-level security to control the

visibility of data at the field level
 Introduction
†

In Salesforce, access to records is determined by access to the objects themselves and

then access to particular records. The sharing model determines the access that a
particular user has to records.
Record access is first established by setting organization-wide defaults (OWD), and
then access is further expanded through roles and role hierarchies, giving managers
access to the records owned by users below them in the hierarchy. Sharing rules can be
customized to make the model work for a particular scenario, using public groups, roles
or other criteria. Records can also be manually shared on a record by record basis.
 Salesforce Security Control
†

Role Hierarchy
Users above the owner in the role hierarchy
have access to records owned by the owner.
Field Access
Field-level security can be defined in profiles Sharing Rules
to control visibility to fields within records. A sharing rule allows granting access to
records based on criteria or ownership.
Record Access
Organization-wide default setting determines Manual Sharing
users’ access to records they do not own. Users can manually share individual records
with other users using the Sharing button.
Object Access Public Groups
A user’s profile determines whether a user
A public group can be created for features
can access an object and the access level.
such as sharing rules and folder access.
 Object Access
†

Profiles determine object access and permissions

Create

Read
Profiles determine which
Permissions on
objects a user can access View All and Modify all
objects can be
and what actions they can grants access to all records
set to: Edit
take on those objects. of the object and overrides
sharing settings.

Delete

View All / Modify All

 Object Access
†

Profiles determine access to tabs and apps. There are different tab access settings.

TAB SETTING ‘DEFAULT ON’

Means the tab for the object will be in the navigation bar if it is part of the ‘App’ selected.

TAB SETTING ‘DEFAULT OFF’

Means that it is available for the user to add by customizing tabs.

TAB SETTING ‘TAB HIDDEN’

Means the tab will not be visible for the object.
Object Settings
†
 Record Access
†

Record-level access determines what a user can do with records of a particular object.

Create

Read
OBJECT Object permissions
PERMISSIONS control what users can
Edit do with records
they own.

Delete
 Organization-Wide Sharing Settings
†

Organization-Wide Defaults (OWD) determines access to other users' data for records
they do NOT own.

Changing OWD settings and

increasing default access (e.g.,
from Public Read Only to
Public Read/Write) will take
effect immediately. Changing OWD settings and
decreasing default access in
an existing organization with
significant data will take some
time for Salesforce to
recalculate user access.
 Organization-Wide Sharing Settings
†

LIMITATION
OWD settings do not grant more access than the object access granted in the user’s profile.
 Organization-Wide Sharing Defaults
†

Access options to custom objects and most standard objects

OWD SHARING DEFAULTS DESCRIPTION

Public Read/Write/Transfer Users can view edit and change ownership (only for leads and cases).

Public Read/Write Allows users to view and edit other users records.

Public Read Only Allows users to view other users records but not edit.
Users cannot see other users records unless it is shared or if the user is
Private
above the record owner in the role hierarchy.
Users can perform an action based on if they can perform the action on
Controlled by Parent the parent object e.g. contact actions are controlled by the actions
available on an account.
 Organization-Wide Sharing Defaults
†

Pricebook object access options

OWD SHARING DEFAULTS DESCRIPTION

All users can view pricebooks add pricebooks to opportunities and add
Pricebook: Use
products in the pricebooks to opportunities.

Users can view pricebooks but only users with ‘Edit’ permission on
Pricebook: View Only opportunities or users that have been manually granted access can add
pricebooks to opportunities.

Users do not have visibility to pricebooks and cannot add them to

Pricebook: No Access
opportunities unless it has been manually shared with them.
Organization-Wide Sharing Settings Available for Price Books
†

The organization-wide default

setting for Price Book can be
‘No Access’, ‘View Only’, or
‘Use’.
 Organization-Wide Sharing Defaults
†

Activity object access options

OWD SHARING DEFAULTS DESCRIPTION

Only the owner of the activity and users above the owner in the role
Activity: Private hierarchy can edit and delete the activity. Users that have read access
to the record that is related to the activity can view the activity.
Activity permissions are determined by the access the user has on the
Activity: Controlled by Parent
record or records related to the activity.
 Organization-Wide Sharing Defaults
†

Campaign object access options

OWD SHARING DEFAULTS DESCRIPTION

Users can view, edit, transfer, delete, and report on all Campaign
Campaign: Public Full Access
records.

Campaign Member: Controlled by Only users who have access to the campaign are able to see the details
Campaign of the campaign members related to the campaign.

Campaign Member: Controlled by Only users who have access to the lead or contact records of campaign
Lead or Contact members are able to see the campaign members.
Public Full Access for Campaigns
†

The ‘Public Full-Access’

setting is only available
for the Campaign object.
Organization-Wide Sharing Settings Available for Campaign Members
†

There are two sharing

settings available for the
Campaign Member object.
 Organization-Wide Sharing Defaults
†

User object access options

OWD SHARING DEFAULTS DESCRIPTION

All users have read access to their own user record and those below
User: Private
them in the role hierarchy.

All users can see one another's user detail pages. They can also see all
User: Public Read Only users in lookups, list views, ownership changes, user operations, and
search.
 Organization-Wide Sharing Defaults
†

Personal calendar object access options

OWD SHARING DEFAULTS DESCRIPTION

Others can see whether the user is available but cannot see any
Calendar: Hide Details
information about the user's calendar events.
Calendar: Hide Details and Add Same as Hide Details with the addition of being able to insert events in
Events other user's calendars.

Calendar: Show Details Users can see information about events in other users calendars.

Calendar: Show Details and Add Same as Show Details with the additional of being able to insert events
Events in other user's calendars.

Users can see all event details, insert events, or edit events in other
Full Access
user’s calendar.
 Record Access
†

NOTES
If a custom object is on the detail side of a master-detail relationship with a standard object, the OWD setting
will be ‘Controlled by Parent’ and cannot be changed.
User visibility will affect which users are displayed in the People tab of Chatter. If user visibility is set to
Private, then users will not see any other users.
 Learn More
†

Control Access to Records

Set Your Organization-Wide Sharing Defaults

 Field Access
†

Access to specific fields can be controlled.

CONTROL OF DATA VISIBILITY

Field-level security controls visibility to data within records at the field level.

REQUIRED EDITIONS
Available in Professional, Enterprise, Performance, Unlimited, Developer, and Database.com
Editions.

ALLOWED SEARCHING OF FIELD VALUES

Field-level security does not prevent searching on the values in a field.
Untick Visible For Field
†

A field can be unticked as

“visible” for any profile, even
those with “View All” and
“Modify All” profile permissions.
 Field Access
†

Field access options

Read-only field-level Field-level security will Universally required fields

FIELD security will override override the ‘Modify All override field-level security and
ACCESS the ‘Edit‘ permission on Data’ and ‘View All Data’ will appear on edit pages
the object. permissions. regardless of field level security.
Set Visibility and Read-Only Attributes
†

PROFILE-BASED VISIBILITY AND READ-ONLY

Fields can be set to not visible or read-only based on profile.

Visibility and Read-Only attributes

of a field can be set per profile
using field-level security.
 Learn More
†

Set Page Layouts and Field-Level Security

Control Who Sees What

 Role Hierarchy Access
†

ORGANIZATION ROLE HIERARCHY

The role hierarchy grants access to records to users
that have a role above the record owner in the role
hierarchy.

For example, a sales manager will have access to all

of his sales team records if the sales manager has a
role above the sales reps in the hierarchy.
 Role Hierarchy Access
†

RECORD ACCESS
The role hierarchy allows additional record access when the object OWD setting is set to more
restrictive than Public Read/Write, e.g., Private/Public Read-Only.

DATA ACCESS HIERARCHY

The role hierarchy is not an organization hierarchy. It should be thought of as a data access
hierarchy.

USER PROFILE OBJECT ACCESS

Role hierarchy access does not override object access determined by profiles. For example, if the
role hierarchy setting for Opportunities is set to Edit, but the users' profile object permission for
opportunities doesn’t have Edit, they will not be able to Edit opportunities.
 †Role Hierarchy Access
Role hierarchy is a way that access to records can be controlled based on a user’s role.

Roles are accessed via Manage Users > Roles.

Access to records of custom objects via the role

hierarchy can be disabled by unchecking 'Grant
Access Using Hierarchies'. This setting is always
enabled for standard objects and cannot be
disabled.
Access to records of standard objects via
hierarchies is enabled by default and cannot
be disabled.
Grant Access Using Hierarchies Checkbox
†
 Exact Access
†

Exact access to contact, opportunity, and case records can be specified.

Access can be set to:

ACCESS NO ACCESS
TYPES

These options only appear

VIEW depending on the OWD settings of
the object; they will not appear if
the OWD setting is public.
EDIT ACCESS
Specify Exact Access
†
Control Record Access via Role Hierarchy
†
 Learn More
†

Create a Role Hierarchy

Use Role Hierarchy

 Manager Group Access
†

Manager groups allow users to share records up or down their management chain.

‘Manager Groups’ can be enabled Once enabled, users can share Manual sharing, sharing rule, or
on the ‘Sharing Settings’ page. It is records with their managers or Apex managed sharing can be
based on the Manager field on the manager subordinate groups. used to share records with
user detail page. a manager group or manager
subordinates group.
Enable Manager Group Sharing
†
Use Manager Groups in Sharing Rules
†
 Learn More
†

Sharing Records with Manager Groups

 Manual User Sharing and Visibility Report
†

MANUAL USER SHARING

Users can be enabled or prevented from sharing their own user records with other users across the
organization by selecting the 'Manual User Record Sharing' checkbox on the 'Sharing Settings' page.

The Sharing button on user detail pages enables a user to grant others access to the user’s own user record.

VISIBILITY REPORT
It is possible to control the visibility of standard reports that might expose data of users to whom a user doesn’t
have access by selecting the 'Standard Report Visibility' checkbox.

Selecting the 'Standard Report Visibility' checkbox allows users to view reports based on standard report
types that can expose data of users to whom they don’t have access.
Manual User Sharing
†

Manual User Record Sharing

and Standard Report
Visibility can be controlled
from the Sharing Settings
page.
 Sharing Rules
†

Sharing rules allow record access to be:

Granted to other users based on Extended across the role Extended across the territory
their role, territory, public group hierarchy, sharing records owned hierarchy, sharing records owned
membership or manager groups, by one role with users in another by users in a territory or with
that they wouldn’t normally role at the same level users in a territory
have access to according to the
organization-wide sharing settings
 Sharing Rule Example
†

BASIS OF RECORD SHARING

Records to be shared can be based on record owner or record criteria, e.g., record type.
Using Record Criteria Sharing
†
 Sharing Rules
†

Sharing rules extend the access that have been established via the OWD and role hierarchy.

CONSIDERATIONS

Access granted can be ‘Read Only’ or ‘Read/Write’.

Sharing rules for campaign members can inherit from lead and contact rules or from the campaign.

If a sharing rule allows a user to view or edit certain records but the user's profile does not give them ‘read’
access to the object, then the user will not be able to access the records associated with the sharing rule.

A profile determines at the base level what can be done with the records of a certain object, while a sharing rule
opens up access to the records of the object.

For instance, if a sharing rule has been created to allow a public group of users to ‘read/write’ certain account
records, but the profile of one of the users does not grant 'read' access to the Account object, then the user will
not be able to view the records via the sharing rule.
 Learn More
†

Trailhead — Define Sharing Rules

Sharing Rules
 Manual Sharing
†

Manual sharing allows users to share records with other users on a one-off basis.

LIMITED TO SALESFORCE CLASSIC

This is a Salesforce Classic only feature. There is no manual ‘Sharing’ button available in Lightning
Experience.

ACCESS TO SHARING BUTTON

The ‘Sharing’ button will only display if appropriate, e.g., if the OWD setting for the object is
private or public read-only.

RECORD SHARING
Records can be shared with other Users, Roles, Roles and Subordinates, Territories, Territories
and Subordinates, Public Groups, Manager Groups or Manager Subordinate Groups.
 Manual Sharing
†

What a user should be to manually share a record

OWNER OF THE RECORD

USER
● A user with full access
ABOVE THE OWNER IN can view, edit, delete and
THE ROLE HIERARCHY transfer a record.
● The user can also extend
USER WITH sharing access to other
users but cannot grant full
‘FULL’ ACCESS
access to the users.

ADMINISTRATOR
 Manual Sharing
†

Manual sharing access options

READ/WRITE
view and edit, add associated records,
notes and attachments

READ ONLY
view, add associated records, cannot
edit or add attachments or notes
 Manual Sharing
†

Manual User Record Sharing options

TURNED ON
Users can manually share records with
other users using the ‘Sharing’ button on
objects including accounts, contacts, leads,
ON
users, cases and custom objects.

TURNED OFF
Sharing of user records can be disabled with
OFF the ‘Manual User Record Sharing’ checkbox
on the Sharing Settings page.
Sharing Button in Salesforce Classic Only
†
Manually Share Records
†
Enable Manual User Record Sharing
†
 Record Access Summary
†

Several Salesforce features are available at different levels in order to restrict or open up
access to records.

RECORD ACCESS LEVELS

Access to objects is first defined at the object level for a user profile for records the user owns.

Organization-wide default settings open up access to records the user does not own for specific objects.

Sharing rules open up record access to users when the OWD settings are set to anything more restrictive than
Public Read/Write.

Individual records can be manually shared using the ‘Sharing’ button.

 Record Access Summary
†

Record access in Salesforce is based on the concept of opening up record access from
more restrictive to less restrictive.
LEAST RESTRICTIVE
RECORD ACCESS
MOST RESTRICTIVE
OWD
OBJECT SHARING
SETTINGS MANUAL
Profile object RULES
Organization- SHARING
permissions Sharing rules
Wide Default Users can
and permission record access is
Settings manually share
set determine granted based
determine records with
access to on record
access to other users.
records owned. owner or
records NOT
owned. criteria.
Record Access Summary
†
 Public Groups
†

Public groups can be used in an organization and may contain specific users, users in particular
roles or territories, users in roles and those below them in the hierarchy, and other public groups.

Groups of users can be made up of other Public

Groups, Users, Roles, Roles & Subordinates,
Territories, and Territories & Subordinates.

Public Groups are used for Sharing Rules,

Folder access, Sharing Records, and adding
Users to a Content Library.

Only Administrators can create Public Groups.

Public Groups Setup
†
 Additional Sharing Options
†

Some Salesforce features or settings can be shared with other users in the organization.

LIST VIEWS QUEUES

Can be shared with: Can be shared with:
● All Users ● Public Groups
● Roles ● Users
● Public Groups ● Roles
● Roles & Subordinates ● Roles & Subordinates
● Territories ● Territories
● Territories & Subordinates ● Territories & Subordinates
Sharing List Views
†
 User Request Scenario 1
†

Read the following user request scenarios for access or restrictions to data. Consider what
features of the Salesforce sharing model would be most appropriate to meet the requirement.

USER REQUEST SCENARIO SECURITY CONTROL

Everyone should be able to see all opportunities, but ● Set OWD for opportunities to Public read.
only Managers should be able to see the Opportunity ● Set the field level security for Opportunity Value to
Value. visible only for users with the Manager profile.
 User Request Scenario 2
†

USER REQUEST SCENARIO SECURITY CONTROL

Users work competitively and do not want to let other Set OWD for contacts to Private.
users see the information of their contact.
 User Request Scenario 3
†

USER REQUEST SCENARIO SECURITY CONTROL

Typically, no one should be able to see each other’s ● Set OWD to Private for contracts.
contracts, but users share on a record by record basis ● Put the “Share” button on the contract page layout,
when needing help with re-negotiation. and show users how to manually share the records
(Salesforce Classic only).
 User Request Scenario 4
†

USER REQUEST SCENARIO SECURITY CONTROL

The sales team should not see other’s opportunities, ● Set OWD for Opportunity to private.
but their managers need to see everyone on their ● Establish a role hierarchy.
team’s opportunities. At the same time, Finance and
● Have sales at the bottom, with managers in a role
the company president should have access to all
above them.
opportunities.
● Put finance above managers, and the president
above all other roles.
 User Request Scenario 5
†

USER REQUEST SCENARIO SECURITY CONTROL

A company has many branches. Each of the branch’s ● Set OWD to private for customers.
employees are in a variety of roles, but need access to ● Create public groups for each branch.
all customers owned by users from their branch. They ● Create a customer sharing rule to share with that
should not be able to see customers from other branch’s public group, if the owner is from that
branches. branch.
 User Request Scenario 6
†

USER REQUEST SCENARIO SECURITY CONTROL

An organization would like to allow its marketing Set the organization-wide default sharing setting for
department to be able to see only the details of the the Campaign Member object to 'Controlled by Lead
campaign members whose contact or lead records or Contact'. It would allow all users to see only the
they have access to. campaign members whose contact or lead records
they have access to in Salesforce.
 User Request Scenario 7
†

USER REQUEST SCENARIO SECURITY CONTROL

Users of an organization are currently only able to see ● Set the organization-wide default sharing setting
campaign members whose lead or contact records for the Campaign Member object to 'Controlled by
they have access to Salesforce. However, the Campaign'. It can be used to allow users to only be
Marketing Director would like them to access able to see campaign members if they have access
campaign member records only if they have access to to the campaign associated with them.
the related campaign. Also, users belong to a certain ● Since the Campaign Member object would inherit
public group require access to all campaign members sharing rules from the Campaign object, a campaign
regardless of the default access. sharing rule can be created to give the public group
access to all the campaigns, which would
automatically give access to the related campaign
member records.