Skip to main content

Grant Access Using Hierarchies

Problem

There is a custom object say 'XYZ' and OWD for this is set to 'Private', which means record of this can be seen by only owner and users above in role-hierarchy and territory. However, to share this with other user, we can manually share it. The problem is that I don't want other users, who are above in role-hierarchy and territory of the user with whom record has shared, can see it.

Solution

We can un-check 'Grant Access Using Hierarchies' check box for object 'XYZ' on 'Sharing Settings' page. We can go to Setup >> Security Controls >> Sharing Settings and click on 'Edit' button. On the edit page, we can un-check 'Grant Access Using Hierarchies' for required object. 



Major uses of 'Grant Access Using Hierarchies' are:-


  1. 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.
  2. 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.
  3. 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.
  4. 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 the Grant 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

However, there is limitation with this too:-


  1. 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.
  2. The Grant Access Using Hierarchies option is always selected on standard objects and is not editable.
http://help.salesforce.com/apex/HTViewHelpDoc?id=security_controlling_access_using_hierarchies.htm

Comments

Post a Comment

Popular posts from this blog

Mashup Integration in Salesforce

During preparation for TA certification exam, I came across a word Mashup for integration a number of times. I explored about it and below is description:- Mashups, sometimes called “composites,” are hybrid applications created by bringing together several data sources and Web services to create a new application or to add value to an existing application. Behind the scenes, mashups may require different levels of integration, depending on whether the mashed-up data is only meant to be viewed, whether it can be edited, and whether data is actually transferred between systems. There are three types of mashup:- Client Presentation Mashup - In this type of mashup the integration takes place strictly at the visual level. It makes possible to view data from two or more applications in a browser,  without actually moving data between the applications. Example - Google Maps. Client Service Mashup - As mashups evolve, they are becoming more complex and sophisticated. Client...

Make Calls to PageReference.getContent() in Asynchronous Apex - Winter16

You can now make calls to the getContent() and getContentAsPdf() methods of the PageReference class from within asynchronous Apex such as Batch Apex, Schedulable and Queueable classes, and @future methods. This allows you to design much more flexible and scalable services that, for example, render Visualforce pages as PDF files.