setting-up-sf-roles

Creating and Setting up of Role Hierarchies

With the Organization-Wide Default, we have locked down access to the different Objects within Salesforce. For example, if we set certain Objects to Private, this means that only the Owners have access to the records within those Objects. In this example wherein the organization-wide defaults are somewhat restrictive than Public Read/Write, there is a way to make records more accessible to users, and the first steps are through the Role Hierarchy.

To start setting up your Role Hierarchy, kindly go to Setup > Enter Role on the Quick Find Box > Click Roles under the User Section

sf-roles-pic

Role Hierarchy determines the level of access that users have to your Organization’s data in Salesforce. These roles within the hierarchy affect access to key components such as records and reports.

sf-role-hierarchy

Role Hierarchy in a technical standpoint means that the Roles that are higher on the Role Hierarchy will inherit full record access to records that are owned by roles lower in the Role Hierarchy.

Scenario 1

Record A is owned by a Western Sales Rep and the Organization-Wide default is set to Private, what level of access will the Western Sales Director have?

sf-role-sample

Answer: The Western Sales Director will automatically inherit the View, Edit, Share, Transfer, and Delete access to this person’s record.

Role Hierarchy opens access upwards and this gives supervisors, directors, VPs, CEOs, the same level access that their subordinates have to the record; provided that their profile permits it. A CEO may have access to everybody’s records but if they’re Profile is set to READ ONLY, then they can only view these records.

Scenario 2

An Account object is one of the Parent objects in Salesforce. Accounts have a special connection with three other objects – Contacts, Opportunities, and Cases. So if you are the owner of an Opportunity, Case, and/or a Contact, as these three are connected to Accounts, by default you also get read access to the related accounts. As an example, see the diagram below:

sf-role-scenario

  • Rep B is the owner of Contact 2 and by default has Read Access to Account 1 though it is owned by Rep A.
  • Rep C is the owner of Case 1 and by default has Read Access to Account 1 though it is owned by Rep A but also inherit access to the related contacts.

Question:

On the Diagram above, Rep A is the owner of Account 1. Should he have access to Contacts, Cases, and Opportunities that he doesn’t own that is associated with Account 1?

Answer:

It depends on Rep A’s role if he will have access to the associated records.

Remember that Role Hierarchy open access upwards but you can also control what level of access owners of a Parent Object Record (e.g. Account Record) will have to records that they don’t own that are associated to the Account Record they do own. This is through Roles. Roles determine user access to cases, contacts, and opportunities, regardless of who owns those records. You can specify the access level by going to the Role Edit page. For example, you can set the Opportunity access so that users in a Role can edit all opportunities associated with accounts that they own, regardless of who owns the Opportunities.

sf-sales-rep

Another example is with the US Sales Rep Role above; you will notice that there is no option to restrict users in this role to not access contacts that they do not own that are associated with accounts that they do own. In this instance, the Organization-Wide Default access for Contacts is set to Public Read Only, which means everybody in the organization will have Read Access to All Contacts in the database as long as their Profile provides that permission.

Note: If you are the owner of the Child object you inherit read access to the Parent object, but as the owner of the Parent Object, it depends on your Role whether you can access these Child Objects.