Roles

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.

1-10-2013 1-32-01 PM

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.

1-10-2013 3-36-55 PM

 

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:

1-10-2013 5-08-10 PM

Result

What access does Jim have to Bob’s account records?

What access does Bob have to Jim’s account records?

Open Result

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.

68 Responses to “Roles”

  1. sheedhu May 13, 2017 at 3:36 pm #

    Hi John,
    I am still getting confused.. How can we choose the level of access which a manager gets to his subordinates records.. Is that controlled by the profile level access..I mean if the manager’s profile has CRED access, and OWD for the object is set to private, will he be able to Read, Edit and Delete his subordinate’s records.. or is there any other way, in which we change the level of access for his subordinate’s records. For ex.. can we restrict the manager to only have Read permission for his subordinate’s records?

    • JohnCoppedge May 16, 2017 at 2:41 pm #

      On standard objects, role inheritance will always take place. On custom objects this is a setting that you can tweak.

      In terms of what the user can actually do… remember that you need both record access and object access to take an action. Just b/c the user has Full Access as granted through the role hierarchy doesn’t mean they can delete that record, they also need the “delete” object permission.

      So it is not uncommon for the Delete permission to be revoked completely for almost all users in an implementation.

  2. anumedha May 12, 2017 at 2:13 am #

    Hi John
    Please help me if i am thinking right.
    sharing setting determine who can see whose records while Profile determine what can be done with the record (CRED) that can be seen using role heirarchy.

    Thanks
    Anu

    • JohnCoppedge May 12, 2017 at 6:28 pm #

      Mostly correct…

      It’s really least access: you need both object and record level security to perform an action.

      Profile grants object

      OWD, record ownership, and role hierarchy grant record level access

  3. bgonzalez April 18, 2017 at 6:44 pm #

    I am having a hard time understanding this statement “Jim can view, edit, and delete Bob’s account records” and if the OWD is set to private

    I thought the profile is what a user can do at the object level. If this is involving the role hierarchy, wouldn’t this be a role trait and what records Jim can view, edit, and delete?

    • MichaelMoeller May 3, 2017 at 7:51 pm #

      In the third bullet point “No sharing rules or any other settings influencing record-level security have been configured.”, I’ve taken this to mean that the Object Account has Grant access using hierarchy enabled. This would mean that since Jim is on a higher level he can see Bobs records. Since Jim’s profile has CRED rights, he will have full access to Bob’s records, this will supersede the OWD.

      Youtube Who sees what on the Salesforce Channel, they have a 5 minute video that goes over this extensively.

    • JohnCoppedge May 12, 2017 at 6:29 pm #

      Pls see the comment above – security is an intersection between different layers, all of which are required

      So profile grants object access, but you still need record access in addition

  4. mkandil7 April 5, 2017 at 4:20 pm #

    I have an issue, when I edit the Roles, I can’t see the options where I can select the level of access for Opportunities and Cases, as seen in the Who sees what series by Salesforce. I am not sure why, is it the new version ? It could be an obvious thing, but I am frustrated ….

    • JohnCoppedge April 5, 2017 at 4:31 pm #

      Check and see if your org wide defaults on account, opp, etc are set to public read/write- you may need to set them to private or read only

  5. jcohen2014 March 7, 2017 at 5:29 pm #

    I read all the comments, but not sure this is stated here – to confirm – from the below question – does this mean that the role hierarchies overrides the profile? Even if Bob has CRED for the accounts object he still cannot view Jim’s records due to role hierarchy?
    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.

    • JohnCoppedge March 13, 2017 at 2:10 pm #

      I wouldn’t think of it an as “override”. You need all permissions in order to perform an action…

      E.g. if I want to update the status field on an account record:
      -I need to be able to login (ip ranges, etc… profile/permission sets)
      -I need to be able to read and update the object (e.g. account… profile/permission sets)
      -I need to be able to read an update the specific record (this is where role hierarchy comes into play – if Org-wide defaults are private then you need some other way to grant access, such as being higher in the role hierarchy)
      -I need to be able to access the specific field I want to update (status… profile/permission sets)

  6. 123tharun January 4, 2017 at 8:59 pm #

    Hello ,

    Could you please explain on the bellow.

    Users in this role cannot access cases that they do not own that are associated with accounts that they do own
    Users in this role can view all cases associated with accounts that they own, regardless of who owns the cases
    Users in this role can edit all cases associated with accounts that they own, regardless of who owns the cases

  7. EESHA October 21, 2016 at 6:07 pm #

    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.

    • JohnCoppedge October 21, 2016 at 8:24 pm #

      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).

      • anumedha May 12, 2017 at 5:17 am #

        Hi John
        i created two user with same profile
        user 1 Manger
        user 2 subordinate

        and give them edit access for account and make OWD for account read only .
        User 1 was able to edit account record of user 2 .
        which is opposite of ur Comment
        Please let me know what is right?

        • JohnCoppedge May 12, 2017 at 5:51 pm #

          User 1 being a manager results in EDIT permissions to records owned by user 2, so this is correct.

          User 1 would also need object level EDIT access (granted via profile or permission set).

          User 2 would be granted read access to records owned by user 1 via OWD, and would not get edit access (even with edit specified on profile/permission set). Hope that clarifies.

  8. sneha06 October 1, 2016 at 3:54 pm #

    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??

  9. MKlobe May 19, 2016 at 2:01 am #

    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!

    • JohnCoppedge May 19, 2016 at 11:09 am #

      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.

  10. choudhary.saurabh@gmail.com April 29, 2016 at 1:28 am #

    Thanks

  11. choudhary.saurabh@gmail.com April 28, 2016 at 5:06 pm #

    Can somebody answer please?

  12. choudhary.saurabh@gmail.com April 20, 2016 at 9:39 pm #

    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?

  13. PrashantKumar February 29, 2016 at 7:07 pm #

    Thank you John

  14. PrashantKumar February 26, 2016 at 4:25 pm #

    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

  15. PrashantKumar February 26, 2016 at 4:22 pm #

    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.

    • JohnCoppedge February 26, 2016 at 10:58 pm #

      Correct- the manager would NOT have ED access to the record.

      • IV July 26, 2017 at 5:32 pm #

        Hi John,

        What if we take the same scenario as above, but reverse the profile permissions:
        Manager – Profile (CRED)
        Subordinate – Profile (CR)
        OWD – Private
        Any other type of sharing – None

        Would the Manager now have (ED) capabilities on the Subordinate’s records even though the subordintate does not?

  16. tejalr8@gmail.com February 4, 2016 at 9:56 pm #

    and pls conciser OWD is more restricted then Public read/write for opportunity record.

    Tejal.

  17. tejalr8@gmail.com February 4, 2016 at 9:53 pm #

    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.

    • JohnCoppedge February 4, 2016 at 11:08 pm #

      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).

      • anumedha May 12, 2017 at 5:24 am #

        The role hierarchy would grant edit access to the record, but not to edit opportunities (object level security).
        What is the diffirence between
        Edit access to the record and
        Edit opportunities

        Thank
        Anu

  18. Munira Majmundar October 13, 2015 at 3:13 pm #

    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

    • JohnCoppedge October 14, 2015 at 11:05 am #

      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

  19. lfunke September 2, 2015 at 8:06 pm #

    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?

    • JohnCoppedge September 3, 2015 at 1:34 pm #

      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.

  20. richa.midha@outlook.com August 19, 2015 at 1:54 am #

    okay thanks! Does that include transfer ability too?

  21. richa.midha@outlook.com August 18, 2015 at 6:36 pm #

    role hierarchy cannot provide complete access; what does it mean by complete access?

    • JohnCoppedge August 18, 2015 at 9:38 pm #

      Are you referring to a specific statement? Full access is granted through the role hierarchy and grants the ability to delete records.

  22. Christopher Chalmers March 25, 2015 at 3:14 am #

    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!

    • JohnCoppedge March 25, 2015 at 4:17 pm #

      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).

      • Kat Radzetskaya April 21, 2015 at 3:43 pm #

        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!

      • Kat Radzetskaya April 21, 2015 at 3:44 pm #

        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.

  23. Cloud Force March 14, 2015 at 4:07 pm #

    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.

    • JohnCoppedge March 15, 2015 at 5:11 pm #

      Yep – sharing rules, manual sharing, etc. – definitely ways to extend beyond the default access.

  24. Ashley Bell February 11, 2015 at 4:51 pm #

    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?

    • JohnCoppedge February 13, 2015 at 1:32 am #

      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.

  25. Jessica Ngoon October 7, 2014 at 12:41 am #

    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!

    • Scott Waddell October 7, 2014 at 11:10 am #

      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. 🙂

      • JohnCoppedge October 14, 2014 at 1:32 am #

        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.

        • Lee Sauer February 7, 2015 at 11:22 pm #

          And Permission Sets are the exception to this since access is determined by Profile plus Permission Sets. Am I understanding this correctly?

          • JohnCoppedge February 8, 2015 at 6:23 pm #

            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.

  26. Alex Messinger September 26, 2014 at 1:25 pm #

    “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.

    • Alex Messinger September 26, 2014 at 1:34 pm #

      Or maybe I’m not understanding it..

      • JohnCoppedge September 27, 2014 at 7:54 pm #

        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 🙂

  27. Synthia Beauvais September 21, 2014 at 10:34 pm #

    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.

  28. Scott Waddell September 16, 2014 at 4:35 pm #

    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?

  29. anusha pudota August 6, 2014 at 5:58 pm #

    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?

    • JohnCoppedge August 7, 2014 at 8:48 pm #

      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?

    • Yogesh Kshatriya December 29, 2014 at 5:52 am #

      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.

Leave a Reply