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 this include:
An option on your organization-wide default 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 administrators.
Events marked as private via the Private checkbox are accessible only by the event owner. Other users cannot 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 Salesforce Communities is enabled in your organization.
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 that has been granted “Full Access.”
If the sharing model is set to Public Read/Write/Transfer for cases or leads or Public Full Access for campaigns, any user can delete those types of records.
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
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 still not be able to edit contacts they do not 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.
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.
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.
In 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.
Professional Edition customers cannot manage users this way because custom profiles are not enabled in Professional Edition organizations.
To segment visibility between business units while maintaining existing behavior within a business unit:
Set the campaign organization-wide default to Private.
Create a sharing rule to grant marketing users Public Full Access to all campaigns owned by users within their business unit.
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.
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.
The organization-wide sharing default for contacts is not available to organizations that have person accounts enabled.
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.