Part 2 – Role Hierarchy
In our first post, we discussed whether “To Share or Not to Share” your Salesforce data with Organization Wide Defaults or OWD. We outlined the basics and reviewed how best to architect your success according to your business needs. In this post, we will take it up a notch. In some requirements, records of a specific Object should not be editable or even seen by all users in your Salesforce environment. In that case, you will set the OWD to either “Public Read-Only” or “Private”. If you opt to set your OWD to anything more restrictive than “Public Read/Write”, it’s now time to explore the next stage in your “great sharing adventure”: Role Hierarchies!
Here’s a scenario — you’ve set your OWD to “Private” and within 10 minutes you receive an alarming influx of emails from the VP of Human Resources, your Sales Rep Manager and even the CEO. They each tell you that they cannot see all of the records in Salesforce — only the ones that they own! Even worse, their reports and dashboards are “totally messed up”– code for missing data! You may be thinking, “I’ve just implemented a layer of security across my Org and it’s working. Great!” But in reality, you’ve just halted collaboration right in its tracks. Setting your OWD to “Private” without Role Hierarchies blocked important Roles in your company from doing their jobs properly. To resolve these issues, let’s take a look at the best practices for building a Role Hierarchy in your Org.
The Natural Way of Sharing
In a work environment, there are typically job titles and positions. And, unless you are the CEO, there is someone above your title, perhaps your manager or the head of your department, who holds you accountable for your work. In order to monitor your work effectively, they need access to the records you own. This is what I call the “natural way of sharing” — anyone above you in either title or role should have access to your records.
The Role Hierarchy resembles this “natural way of sharing”, and it’s your first utility when it comes to opening up access to records in Salesforce. Furthermore, it plays a critical “role” with reporting, forecasting and running dashboards in Salesforce.
The Role Hierarchy doesn’t need to exactly match your organization chart. In fact, you could implement your Role Hierarchy to support a number of scenarios. These include:
- Territory-based: The most commonly used, this Role Hierarchy model divides your roles based on where people are located.
- Product-based: This structure is most often used when you have multiple products and you need a dedicated, distinct team to support each product in your Org.
The structure all depends on your business needs. The best definition of a Role is: a group of people who need the same level of access to records they do not own.
How to Set-up Roles in 6 Easy Steps
If you’d like to create new Roles for your Org, follow these steps:
- From the Setup Menu, type “Roles” in the quick Find,
- Click on the Roles item below Manage Users,
- Find the level in the Role Hierarchy you want to add the new role, then Click “ Add Role” below its parent role. In this example, you will add a role below the role named “CEO”.
- Input the required information.
- Select the level of access for Account related records.
a. Cases & Opportunities are both related to an Account. It’s very likely that an Account will have multiple Cases and opportunities owned by different users. You need to specify what type of access, if any, the members of this role should have to related records they do not own for these objects.
- Click Save.
3 Golden Rules on Role Hierarchies
To better understand access through the Hierarchy, imagine yourself in the role of “Junior CFO, North America” and ask yourself these three questions:
- Who is my Parent?
Rule #1 – Any role that sits directly above you will have access to the records you own, however you will not be able to see the records they own. In this case, the CFO’s records will not be visible to you.
- Who are my Siblings — the roles that are next to you?
Rule #2 – Your siblings, by default, will not be able to access the records you own. In this case the CFO, International’s records will not be visible to you.
- Who are my Children?
Rule #3 – Any role that sits directly below you will not have access to the records you own, however you will be able to see their records since you are their Parent.
It’s Pop Quiz Time!
For the “VP, North American Sales” Role, can you answer these questions:
- Who will be able to see, by default, all the records owned by the role?
- Who are the Siblings of the role?
- Will records owned by the Director of Channel Sales be visible by the role?
- Bonus: Will records owned by Director of Direct Sales be visible to the VP of Marketing?
- SVP, Sales & Marketing
- VP, International Sales & VP, Marketing
In Part 3, we will add another layer to our Sharing model by adding an exception to the Second Golden Rule (sharing records with Siblings in the Role Hierarchy) by employing Sharing Rules to share records across Siblings and Public Groups.
About the Author
Clara Perez is a Salesforce MVP and Lead Developer at Great Wave who loves teaching Salesforce concepts.