Copy of knowledge article from here:
Controlling Access Using Hierarchies
|Available in: Professional, Enterprise, Performance, Unlimited, Developer, and Database.com Editions
Territories are not available in Database.com
|User Permissions Needed|
|To set default sharing access and change the Grant Access Using Hierarchies option:||“Manage Sharing”|
Beyond setting the organization-wide sharing defaults for each object, you can specify whether users have access to the data owned by or shared with their subordinates in the hierarchy. For example, the role hierarchy automatically grants record access to users above the record owner in the hierarchy. By default, the Grant Access Using Hierarchies option is enabled for all objects, and it can only be changed for custom objects.
To control sharing access using hierarchies for any custom object, click Grant Access Using Hierarchies if you want to prevent users from gaining automatic access to data owned by or shared with their subordinates in the hierarchies.and Edit in the Organization Wide Defaults section. Deselect
- Regardless of your organization’s sharing settings, users can gain access to records they do not own through other means such as user permissions like “View All Data,” sharing rules, or manual sharing of individual records.
- The Grant Access Using Hierarchies option is always selected on standard objects and is not editable.
- If you disable the Grant Access Using Hierarchies option, sharing with a role or territory and subordinates only shares with the users directly associated with the role or territory selected. Users in roles or territories above them in the hierarchies will not gain access.
- If your organization disables the Grant Access Using Hierarchies option, activities associated with a custom object are still visible to users above the activity’s assignee in the role hierarchy.
- If a master-detail relationship is broken by deleting the relationship, the former detail custom object’s default setting is automatically reverted to Public Read/Write and Grant Access Using Hierarchies is selected by default.
- The Grant Access Using Hierarchies option affects which users gain access to data when something is shared with public groups, personal groups, queues, roles, or territories. For example, the View All Users option displays group members and people above them in the hierarchies when a record is shared with them using a sharing rule or manual sharing and theGrant Access Using Hierarchies option is selected. When the Grant Access Using Hierarchies option is not selected, some users in these groups no longer have access. The following list covers the access reasons that depend on the Grant Access Using Hierarchies option.
- These reasons always gain access:
- Group Member
- Queue Member
- Role Member
- Member of Subordinate Role
- Territory Member
- Member of Subordinate Territory
- These reasons only gain access when using hierarchies:
- Manager of Group Member
- Manager of Queue Member
- Manager of Role
- Manager of Territory
- User Role Manager of Territory
- When you deselect Grant Access Using Hierarchies, notify users of the changes in report results that they can expect due to losing visibility of their subordinates’ data. For example, selecting My team’s… in the View drop-down list returns records owned by the user; it will not include records owned by their subordinates. To be included in this type of report view, records from subordinates must be explicitly shared with that user by some other means such as a sharing rule or a manual share. So, if no records are shared with you manually, the My… and My team’s… options in the View drop-down list return the same results. However, choosing the Activities with… any custom object report type when creating a custom report returns activities assigned to you as well as your subordinates in the role hierarchy.