Set Up and Maintain Your Salesforce Organization 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 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.
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 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.
375
Set Up and Maintain Your Salesforce Organization Sharing Considerations
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.
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
376
Set Up and Maintain Your Salesforce Organization Who Has Access to Account Records?
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.
Contact Sharing
See: Business Contact Sharing for Orgs That Use Person Accounts
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
Sharing Settings
Who Has Access to Account Records?
A user may have access to an account from:
•
Record Ownership
•
Implicit access from an associated child record such as a case, contact, or opportunity
•
Organization-wide sharing defaults
•
Role hierarchy
•
Sharing rules
•
Manual sharing
•
Account team or territory
To find out why a user have access to the record, click the Sharing button on the account detail page to see a list of users who have access and for which reasons. Click Expand List to see all users who have access.
The following users don’t show up in the list even if they may have access:
•
All users, if the organization-wide defaults are set to Public Read Only or Public Read/Write
•
High-volume portal users
Note: If the Sharing button does not appear, the organization-wide sharing defaults may have been set to Controlled by Parent or Public Read. Otherwise, only the record owner, an administrator, or a user above the owner in the role hierarchy can see the
Sharing Detail page.
377
Set Up and Maintain Your Salesforce Organization Who Has Access to Account Records?
Access Type
Record owner
Implicit access
Organization-wide sharing default
Role hierarchy
Sharing rules
Manual shares
Account Teams and
Territory
Table 2: Troubleshooting guideline for user access to a record
Description
The record owner always gets access to his or her own record.
Corresponds to the “Associated record owner or sharing” entry in the Reason column of the Sharing Detail page. The user may have access to a child record of an account (opportunity, case, or contact), which grants them Read access on that account. You cannot overwrite this access. For example, if the user has access to a case record, he or she has implicit Read access to the parent account record.
Check if the defaults for the account object are set to Private. If it is, the user may have gained access via other methods listed here. It must be set to Private if at least one of your users should not see a record.
The user may have inherited Read access from a subordinate in the role hierarchy. You can’t override this behavior for non-custom objects. If the user who has access is on a different branch of the hierarchy from the account owner, check the sharing rules, account teams, and account territory.
The user may have gotten access because he or she has been included in a relevant sharing rule. If the sharing rule uses public groups (or other categories such as roles) to grant access, check your public groups to see if the user has been included in the group.
The user may have gotten access through the Sharing button of the record. Only the record owner, an administrator, or a user above the owner in the role hierarchy can create or remove a manual share on the record.
The user may have been added to an Account Team by the account owner, an administrator, a user above the owner in the role hierarchy, or an account team member. If your organization uses territory management, check if the user who has access is higher in the territory hierarchy than the account owner. Managers gain the same access as their subordinates. Additionally, if the user is a member of Group A, which is a member of
Group B, he or she gets access to all accounts shared to Group B, at the same level of access as members of
Group B.
SEE ALSO:
Control Who Sees What
Resolving Insufficient Privileges Errors
378
