What is the significance of the role hierarchy?
The role hierarchy provides a framework to structure access to records and folders in your organization. Various settings (sharing rules, groups, folder sharing criteria, etc.) rely heavily on roles to structure access to content. Grant access using hierarchies has a profound impact on record security, as we’ll explore below.
What is the significance of a user’s role?
Each user is assigned one role, which sets the foundation for their access to records and folders.
While a user’s profile and permission sets determine if a user can run reports, their role will influence which report folders they can access.
Grant Access Using Hierarchies
“Grant Access Using Hierarchies” is a setting for configuring organization-wide defaults (Setup –> Security Controls –> Sharing Settings). For most standard objects, the option is always enabled. For custom objects, it is enabled by default but can be disabled.
Users are granted full access (create, read, edit, delete) record-level permissions to the records meeting both criteria:
- The record is owned by a user in a subordinate role.
- The object has “Grant Access Using Hierarchies” enabled.
Notice that Grant Access Using Hierarchies is checked for all objects, but can only be unchecked for custom objects.
Example
- Jim is assigned the role “VP, Northern American Sales”.
- Bob is assigned the role “Director, Direct Sales”.
- Org-wide default security for the account object is set to private. No sharing rules or any other settings influencing record-level security have been configured.
- Jim and Bob are both assigned to a profile that provides CRED (create, read, edit, delete) object-level permissions to the account object.
- The role hierarchy is structured as follows:
Result
What access does Jim have to Bob’s account records?
What access does Bob have to Jim’s account records?
[toggle title_open=”Close Result” title_closed=”Open Result” hide=”yes” border=”yes” style=”default” excerpt_length=”0″ read_more_text=”Read More” read_less_text=”Read Less” include_excerpt_html=”no”]Jim can view, edit, and delete Bob’s account records. Access to Bob’s records is provided by the role hierarchy, as Bob is in a subordinate role.
Bob cannot view Jim’s account records, as the org-wide default for account is private. Jim’s records are not shared with Bob, as Jim is in a higher role.[/toggle]
Hi John
This statement has me a little confused as the who sees what series says that profile level permission overrides all other permissions.so if the user has edit access at profile level and read access on the record how can the user not be able to edit the record.one can only open up access not restrict it???
Spot on Scott. Security works on the principal of least access. That is to say that the user needs access in all ways (record-level, object-level, field-level security) – whichever access is lowest will indicate which level of permission the user is granted.
Therefore if you have edit access to the object, and only read access to the record, the user cannot edit the record.
Might be a mix up in terms- the profile does not “override” the other permissions in the system (the only exception would the “view all” and “modify all” permissions which in a sense do override record-level permission). The user would need EDIT access on the object and EDIT access on the record in order to edit the record. Object EDIT and record READ (no edit) would result in READ permissions on the object (lowest common denominator).
Hi John,
Could you please clarify below query.
Criteria-based sharing rules can be created for which objects? (Choose 3)
Opportunities
Contacts
Accounts
Campaigns
Leads
In my opinion Criteria-based sharing rules is present for all objects. Then why it is true only for first three??
I believe you’re right- the question is probably wrong
What’s the significance of the graphic you put where you stated…
“Notice that Grant Access Using Hierarchies is checked for all objects, but can only be unchecked for custom objects”
Thanks!
Grant access using hierarchies is what provides access to users higher in the hierarchy. Eg if Jim is above bob in the hierarchy then Jim inherits record access to bobs records. This can be turned off for custom objects- which would mean that Jim would not inherit access to bobs records.
Thanks
Can somebody answer please?
Hi John, can you please answer the following scenario –
The OWD is set to Private. User 1, the owner of ABC Company account, is a US Sales Rep reporting to US Sales Dir. The users in the US Sales Rep role can edit ALL Opportunities associated with the accounts they own. User 2, an EMEA Sales Rep, owns an Opportunity associated with ABC Company. Identify the correct roles access –
1. User 1 can VIEW but cannot EDIT Users 2’s ABC Company Opportunity
2. User 2 cannot VIEW or EDIT User 1’s account
3. User 1 can VIEW and EDIT User 2’s ABC Company opportunity
4. User 2 can VIEW and EDIT User 1’s account
5. User 2 can VIEW but cannot EDIT User 1’s Account
I believe the correct answers are 3 and 5. 3 because of role hierarchy that gives edit access to User 1’s account’s opportunity, but what I am struggling with is how can user 2 view User 1’s account (5)? Is it because he owns an opportunity that belongs to ABC Company account? Which Data Access model principle is this?
Yep I think you’re right there- the principle is implicit record access: http://help.salesforce.com/HTViewHelpDoc?id=faq_record_access.htm
Thank you John
Hi John,
Also wanted to Clarify that
– Profile and permission sets gives access to the various objects
– But others such as OWD, manual sharing, etc give access to records in objects.
Thanks
Yep, spot on!
Hi John,
My question for roles hierarchy is below.
Situation:-
Manager – Profile (CR)
Subordinate – Profile(CRED)
OWD – Private
Any other type of sharing – None
Would the manger have edit and delete (ED) capabilities on the subordinates records?
My thought is tht he should not have (ED) capability based on the profile as you say security based onleast access should kick in.
Correct- the manager would NOT have ED access to the record.
and pls conciser OWD is more restricted then Public read/write for opportunity record.
Tejal.
Hi john,
I have question.
Consider that in my org ..role hierarchy and respected custom profile and the access to the standard object opportunity some what like this..
Manager(ABC) with Profile (abc) have object opportunity access only Create and Read permission.
and further in my role hierarchy , i have one subordinate(XYZ) with differant profile (xyz) , and that subordinate access for opportunity is CRED for opportunity object…!,
First place , is it possible.?
And if ‘yes’ then …can hierarchy will grant manager more access to subordinates record more then only CR access that he had from profile , as he is manager of XYZ with (xyz) profile and and XYZ have CRED access to opportunity?
Tejal.
First- possible: yes
No- security is the sum of all greatest access. In other words, the user needs a profile that will let them edit the opportunity and edit access to the opportunity record – both are required to edit.
The role hierarchy would grant edit access to the record, but not to edit opportunities (object level security).
So John:
Am I correct in assigning following permission on Accounts and Opportunities for the following three cases:
User Case 1: Accounts = Create, Read (object permission)
Opportunity = Private (OWD)
User Case 2: Account = Create, Read (Object permission)
Opportunity = Read (OWD)
User Case 3: Account = Create, Read, Edit (Object Permission)
Opportunity = Read and Write (OWD)
User Case 1: -Users in this role cannot access opportunities that they do not own that are associated with accounts that they do own
User Case 2: -Users in this role can view all opportunities associated with accounts that they own, regardless of who owns the opportunities
User Case 3: -Users in this role can edit all opportunities associated with accounts that they own, regardless of who owns the opportunities
Use Case # 1 correct
Use Case #2 users can view ALL opportunities regardless of account owner.
Use Case #3 users can view and edit ALL opportunities regardless of account owner.
Depending on the settings of you sharing rules and roles, this could be shared based on account owner. E.g. role settings:
Users in this role cannot access opportunities that they do not own that are associated with accounts that they do own
Users in this role can view all opportunities associated with accounts that they own, regardless of who owns the opportunities
Users in this role can edit all opportunities associated with accounts that they own, regardless of who owns the opportunities
Do most companies really use roles this way? It seems like a disaster waiting to happen. Couldn’t an exec, who doesn’t usually use the system, mistakenly screw things up, and maybe even delete accounts or opportunities?
It is possible, yes. Although rare from my experience. Typically execs use Salesforce more for reporting and dashboards – not unusual to have delete access removed.
okay thanks! Does that include transfer ability too?
Full access would yes
role hierarchy cannot provide complete access; what does it mean by complete access?
Are you referring to a specific statement? Full access is granted through the role hierarchy and grants the ability to delete records.
Hi John, can you help clarify something for me please? Watching the “Who See’s What: Record Access Via Role” video number 5. As I understood it, Grant Access Using Role Hierarchy gives a user full access to records owned by their subordinates. What I am not understanding is the concept of these three options when the OWD for an Object, for example, Opportunities is set to Private:
-Users in this role cannot access opportunities that they do not own that are associated with accounts that they do own
-Users in this role can view all opportunities associated with accounts that they own, regardless of who owns the opportunities
-Users in this role can edit all opportunities associated with accounts that they own, regardless of who owns the opportunities
In this video they seem to be completely ignoring the “Account ownership” part of these options, and implying that what you are selecting here is the level of access the User has over their subordinate’s opportunities. That is not at all what I would think when reading these options. In fact, when I read these options I don’t see how the “hierarchy” comes into play at all. To me what this seems to be doing is defining the level of access that users in that role have to opportunities associated to accounts they own that they wouldn’t have access to via some other sharing rule (including the hierarchy).
Is it me, or is the example they’re giving in the video totally wrong and misleading? Again, I was under the impression that Grant Access Using Role Hierarchy gives a manager Full Access to subordinates records, end of story. Thanks!
There are two issues at play here.
One is the role hierarchy which is used to extend access to records owned by users in subordinate roles. This would provide full access to an account owned by a user in a subordinate role, for example.
The second is the role extending access to records via ownership as defined in these role selections. E.g.
-Users in this role cannot access opportunities that they do not own that are associated with accounts that they do own
-Users in this role can view all opportunities associated with accounts that they own, regardless of who owns the opportunities
-Users in this role can edit all opportunities associated with accounts that they own, regardless of who owns the opportunities
What this setting will do is extend access to related cases and opportunities from accounts that users in that role own. E.g. If I am in this role with the last setting selected, then I will be able to edit the opportunities related to any account that I own (regardless of who owns the opportunity). This setting here does not rely on the role hierarchy outside of the above selection for that role (there is no inherited permissions via the hierarchy in this second case).
Hi John,
Where can I find “Who See’s What: Record Access Via Role” video number 5 that Christopher was referring to? I do not see any available videos here.
Thank you!
Hi John,
Where can I find “Who See’s What: Record Access Via Role” video number 5 that Christopher was referring to? I do not see any available videos here.
Look in the security model section: http://beta.certifiedondemand.com/security-model/
Hi John,
What are the possible way(s) for Jim/admin – to give permission to access account records of Jim to Bob or is it not possible?? Note: The scenario is same as mentioned above.
Yep – sharing rules, manual sharing, etc. – definitely ways to extend beyond the default access.
In your example, if Jim’s role was Director Channel Sales and Bob’s role was Director Direct Sales they would both be able to see each others records since they’re at the same level in the role hierarchy?
Nope – access is only granted for roles lower in the hierarchy. Even if they were in the same role, they would not be able to see each other’s records.
First, thanks for everything! These overviews are very helpful 🙂
Question: If the manager doesn’t have edit permissions, but the subordinate has CRED, will the manager get CRED for the record even if his profile doesn’t allow that?
Thanks!
Sharing rules can never grant more access than what the user’s object permissions (i.e. profile) will allow. So in this case the answer would be no. Also note that there is no sharing rule for Create — that’s an object permission. Remember that sharing rules are used to determine whether you can see someone else’s records, so Create doesn’t really make sense in that context. 🙂
Spot on Scott. Security works on the principal of least access. That is to say that the user needs access in all ways (record-level, object-level, field-level security) – whichever access is lowest will indicate which level of permission the user is granted.
Therefore if you have edit access to the object, and only read access to the record, the user cannot edit the record.
And Permission Sets are the exception to this since access is determined by Profile plus Permission Sets. Am I understanding this correctly?
Permission sets and profiles combined determine object level and field level security – record level security through role hierarchy is still observed. The exception would be if you had view all data or modify all data, which is assigned by profile/permission set, and overrides record level security.
“Grant access using hierarchies has a profound impact on record security, as we’ll explore below.”
Should be
“Granting access using hierarchies has a profound impact on record security, as we’ll explore below.
Or maybe I’m not understanding it..
That’s a reference to the specific setting called “Grant access using hierarchies” as shown in the screenshot above. If that statement were not referencing the setting as a noun then your grammatical version would definitely make more sense 🙂
Hi,
This page is not showing any of the screen shots. I had to copy and paste it into a word document just to see it. I am using IE.
Hmm… I will look into that. Thanks Synthia
Hi John,
What if object level permissions didn’t include Edit in your example? The role heirarchy wouldn’t provide more access than the user’s profile, right?
Correct
Hi John,
In OWD, Account is set to ‘private’ and object level permissions are set to CRED for both of them. In order for Jim to have access to Bob’s Account records, the role assigned to Jim shouldn’t have edit permission enabled for Account?!! Am I missing something here? Just as there are options (no access, read, edit) for opportunity and cases on role edit page, aren’t there any actions to be enabled on role to open up the hierarchy for Accounts?
Grant access via hierarchies is automatically enabled (and cannot be disabled) for standard objects. Therefore as Jim is in a HIGHER role (thus grant access via hierarchies would grant read/write to all lower roles) than Bob, Jim would inherit record-level read/write to all accounts that Bob owned.
Does that make sense?
Hi Anusha,
Based on settings tried out to me it looks that the rights (No access, View only, Edit) will only appear for following standard objects only
1. Opportunity
2. Cases
3. Contacts
when the access to above 3 object is set to more restrictive that Public Read/Write in OWD. For any other objects they don’t appear.