4/24/2019 Sharing Considerations

Sharing Considerations
Learn how sharing models give users access to records they don’t own.

The sharing model is a complex relationship between role hierarchies, user permissions, sharing rules,
and exceptions for certain situations. Review the following notes before setting your sharing model.

Exceptions to Role Hierarchy-based Sharing

Users can always view and edit all data owned by or shared with users below them in the role
hierarchy. Exceptions to role hierarchy sharing include:

Enabling a setting on your organization-wide default settings that allows you to ignore the
hierarchies when determining access to data.
Contacts that are not linked to an account are always private. Only the owner of the contact and
administrators can view it. Contact sharing rules do not apply to private contacts.
Notes and attachments marked as private via the Private checkbox are accessible only to the
person who attached them and to administrators.
Events marked as private via the Private checkbox are accessible only by the event owner. Other
users can’t see the event details when viewing the event owner’s calendar. However, users with the
“View All Data” or “Modify All Data” permission can see private event details in reports and
searches, or when viewing other users’ calendars.
Users above a record owner in the role hierarchy can only view or edit the record owner’s records if
they have the “Read” or “Edit” object permission for the type of record.

Visibility to users as a result of the Community User Visibility preference is not inherited through
the role hierarchy. If a manager in the role hierarchy is not a member of a community, but their
subordinate is, the manager does not gain access to other members of the community. This only
applies if Communities is enabled in your organization.

Deleting Records
The ability to delete individual records is controlled by administrators, the record owner, users in a
role hierarchy above the record owner, and any user who has been granted “Full Access.”
If the org-wide default is set to Public Read/Write/Transfer for cases or leads, only the record
owner or administrator can delete the record.

Adding Related Items to a Record

You must have “Read/Write” access to a record to be able to add notes or attachments to the
record.
You must have at least “Read” access to a record to be able to add activities or other associated
records to it.

Adding or Removing Sharing Access Manually

The ability to manually extend the sharing access of individual records is controlled by
administrators, the record owner, users in a role hierarchy above the record owner, and any user
that has been granted “Full Access.”
Changing your sharing model deletes any manual shares your users have created.

User Permissions and Object-Level Permissions

https://help.salesforce.com/articleView?id=security_sharing_considerations.htm&type=5 1/3
4/24/2019 Sharing Considerations

While your sharing model controls visibility to records, user permissions and object-level permissions
control what users can do to those records.

Regardless of the sharing settings, users must have the appropriate object-level permissions. For
example, if you share an account, those users can only see the account if they have the “Read”
permission on accounts. Likewise, users who have the “Edit” permission on contacts may not be
able to edit contacts they don’t own if they are working in a Private sharing model.
Administrators, and users with the “View All Data” or “Modify All Data” permissions, have access to
view or edit all data.

Account Sharing
To restrict users’ access to records they do not own that are associated with accounts they do own,
set the appropriate access level on the role. For example, you can restrict a user’s access to
opportunities they do not own yet are associated with accounts they do own using the
Opportunity Access option.
Regardless of the organization-wide defaults, users can, at a minimum, view the accounts in their
territories. Also, users can be granted access to view and edit the contacts, opportunities, and
cases associated with their territories’ accounts.

Apex Sharing
The organization-wide default settings can’t be changed from private to public for a custom object if
Apex code uses the sharing entries associated with that object. For example, if Apex code retrieves the
users and groups who have sharing access on a custom object Invoice__c (represented as
Invoice__share in the code), you can’t change the object’s organization-wide sharing setting from
private to public.

Campaign Sharing
In Professional, Enterprise, Unlimited, Performance, and Developer Editions, designate all users as
Marketing Users when enabling campaign sharing. This simplifies administration and
troubleshooting because access can be controlled using sharing and profiles.
To segment visibility between business units while maintaining existing behavior within a business
unit:
1. Set the campaign organization-wide default to Private.
2. Create a sharing rule to grant marketing users Public Full Access to all campaigns owned by
users within their business unit.
3. Create a sharing rule to grant all non-marketing users in a business unit Read Only access to all
campaigns owned by users in their business unit.

When a single user, such as a regional marketing manager, owns multiple campaigns and needs to
segment visibility between business units, share campaigns individually instead of using sharing
rules. Sharing rules apply to all campaigns owned by a user and do not allow segmenting visibility.
Create all campaign sharing rules prior to changing your organization-wide default to reduce the
affect the change has on your users.
To share all campaigns in your organization with a group of users or a specific role, create a sharing
rule that applies to campaigns owned by members of the “Entire Organization” public group.
Minimize the number of sharing rules you need to create by using the “Roles and Subordinates”
option instead of choosing a specific role.
If campaign hierarchy statistics are added to the page layout, a user can see aggregate data for a
parent campaign and all the campaigns below it in the hierarchy regardless of whether that user
has sharing rights to a particular campaign within the hierarchy. Therefore, consider your
organization’s campaign sharing settings when enabling campaign hierarchy statistics. If you do
not want users to see aggregate hierarchy data, remove any or all of the campaign hierarchy
statistics fields from the Campaign Hierarchy related list. These fields will still be available for
reporting purposes.

https://help.salesforce.com/articleView?id=security_sharing_considerations.htm&type=5 2/3
4/24/2019 Sharing Considerations

If the sharing model is set to Public Full Access for campaigns, any user can delete those types of
records.

Campaign Member Sharing

Campaign member sharing is controlled by campaign sharing rules. Users that can see a campaign can
also see associated campaign members.

Contact Sharing
See: Business Contact Sharing for Orgs That Use Person Accounts (articleView?
id=security_sharing_b2c_contact_sharing.htm&type=5&language=en_US#business_contact_sharing)

Price Book Sharing

Sharing on price books controls whether users can add the price book and its products to
opportunities.
User permissions control whether users can view, create, edit, and delete price books.

SEE ALSO

Sharing Rules (articleView?id=security_about_sharing_rules.htm&type=5)

Sharing Settings (articleView?id=managing_the_sharing_model.htm&type=5)
Customize Who Has Access to Paused Flow Interviews (articleView?
id=vpm_admin_pause_sharing.htm&type=5&language=en_US)

https://help.salesforce.com/articleView?id=security_sharing_considerations.htm&type=5 3/3