I’ll be honest – the role hierarchy confused the heck out of me when I was a new administrator. Understanding the concept and it’s use was difficult, but it is a vital part of your overall data security model. All Administrators need to become familiar with the function of roles and how to build a strong role hierarchy.
Roles are used in a number of key areas including sharing rules, reports, report and dashboard folders, manual sharing and even workflow rules and formulas. If the role hierarchy is not setup correctly, creating workarounds and generating a lot of manual work will become commonplace. This is why building a strong and scalable role hierarchy is so important.
Before looking at how to build an awesome role hierarchy, it is important to distinguish between a role and profile and why roles are so important.
If we simplify the definition of role vs profile to the most basic level, we get this: roles determine what data you can see and profiles determine what you can do with that data. That’s it! While in practice this is more complicated and there is a bit of overlap, this basic concept will help in differentiating between a role and profile.
To fully understand the function of roles, you need to be familiar with the concept of organization-wide defaults and how data visibility works by default. We know that owners of records, by default can create, view, edit and delete the records that they own. If the org-wide defaults are set to private, the no one in the organization has access to those records – except through the role hierarchy. This is where things get interesting. By default, data flows up the hierarchy. So, in an organization where record access is set to private, managers have at least read access to the records owned by their subordinates.
Now, what if the records you and your team owns need to be shared with a different department or role within the organization? We use sharing rules to share laterally across roles. Take a look at this image which illustrates how data flows vertically up the hierarchy and how sharing rules open data access laterally across the hierarchy.
Okay. Let’s see how to build an awesome hierarchy. Whether you are building a role hierarchy from scratch for a new organization, or you are needed to rebuild a role hierarchy for your existing organization, the steps will be the same. Just like building a house, you always lay the foundation first. That is all we are doing with these fist steps.
Start with the org chart
Every company has an org chart which is already set up in a hierarchical structure. If you aren’t sure that an org chart exists, check with your HR department. After obtaining the org chart, do any reformatting you need to so that it is easy to read and manipulate. There are a number of tools do this with including Excel, PowerPoint or Visio. I recently found a great Google Apps plugin called Lucid Chart which is like a cloud version of Visio but with collaborative features.
Be sure to validate any changes you make with the appropriate department heads. The initial structure needs to be as exact as possible in order to provide a good launching pad.
Understand the companies desired sharing settings
Next, take some time to understand how your organization wants to share data. Who should have access to what – including CRED (create, read, edit, delete) and Org Wide Defaults. This will help us build sharing rules for the new role structure and create the appropriate org-wide defaults. It also helps in understanding how the org chart may need to be manipulated to fit into the role hierarchy based on those sharing rules.
A few key items to remember here:
- Role hierarchies may not resemble the org chart 100%. Each one serves a specific purpose. The org chart is a great starting place but don’t be afraid to revise it when creating the role hierarchy based on requirements.
- If possible, don’t create a 1:1 relationship between a role and a user. Keep the hierarchy as simple as possible and group roles together based on the necessary access level to data based on sharing rule requirements.
- Print several versions of the hierarchy and use colors to indicate sharing rules across the organization. I find that traditional pen and paper works well while finalizing the sharing rules.
After documenting the sharing rules, update your hierarchy document showing the sharing rules and once again, confirm with the department heads that they are correct. Once validated, you can begin making your changes to both the role hierarchy and sharing rules.
While the concept can be confusing initially, the concept of the role hierarchy is not a difficult one to understand. Because it is so vitally important to the way data is shared in your organization, it is important to ensure that it is structured for maximum efficiency. In doing so, it will reduce the amount of manual work needed to share information and reduce the number of sharing rules needed.
4 thoughts on “ How to Build a Rock Solid Role Hierarchy ”
Hi Brent, How to handle scenario where Customer Care Manager should see only his reporting Customer Care Team Lead data ? So Manager in the same role ( peers ) should see data from his reporting users only.
If I understand the question correctly (which is that manager’s should only see their employees information), you’ll need to create 3 levels in the hierarchy for those roles. This will tie into sharing rules as well. Org Wide Defaults should probably be set to Private and you’ll need to create specific sharing rules for the org to provide the appropriate level of access.
Understanding the concept and it’s use was difficult, but it is a vital part of your overall data security model.
It is should be ** its *** not it’s.