Without a planned-out strategy, role hierarchies in Salesforce can quickly get out of hand. Here’s a guide to developing a structure that will last long term.
When a company experiences growth, especially globally, its sales team may start to see less standardization in titles and structure as everyone tries to keep up with the new business. This may lead to a Salesforce team that is no longer able to build a role hierarchy based on titles and is busier than they’ve ever been in the past.
In order to maintain the correct visibility and editing privileges for sales management, it’s time to update your role hierarchy. But where do you start? Due to the lack of standardization, how are you able to bucket employees? And, more importantly, how are you able to build a sustainable role hierarchy that doesn’t need constant change and reassignments?
Included in this article are some key guidelines to help you implement a manageable change to your role hierarchy and keep you focused on more important work to be done within your Salesforce org.
When rebuilding your role hierarchy, a structure similar to this is a good place to start:
This Salesforce role hierarchy structure is based on 5 guidelines:
Be general.
Think management structure, not titles.
Build for easy iteration.
Use standardized names.
Keep visibility in mind.
Be general.
The more detailed the role hierarchy structure, the more you’ll have to do to keep up with it. One of the easiest things to do when building a role hierarchy is to overcomplicate it by trying to account for every detail of your company’s organization. Not everything is going to fit cleanly in a particular bucket — and that’s okay! Start by thinking broadly about how your company’s organization tree is structured with as few branches as possible and only add in the ones that are absolutely necessary. Think about how titles can be grouped together without getting too deep into the specifics.
In the example above, all different representative titles are simply grouped together in one “Representative” level per global region instead of being broken out into Account Executives, Sales Development Representatives, Account Managers, etc. If there isn’t a major difference in what those users need to see, then don’t overcomplicate it. The more general your role hierarchy, the less maintenance you’ll need to do on a weekly basis.
Think management structure, not titles.
One of the most important things to remember when building a role hierarchy in Salesforce is that it shouldn’t be based on titles, it should be based on management levels. Users should be assigned a role based on how many levels of management are above or below them. If you have no one reporting to you, then more often than not, you don’t need as much visibility in Salesforce as someone who is two management levels above you. Exceptions always exist, of course, but the minute you start building your role hierarchy for exceptions, you lose touch with simplicity. Make peace with exceptions and build for the majority.
In the example above, role changes are not required for Salesforce users unless they move to a new management level. If an Account Executive becomes a Sr. Account Executive — no changes are required! If visibility does not need to change, then their role should not need to change. In organizations where the sales team is facing constant promotions and title changes, adopting a Salesforce role hierarchy such as the one above will keep you from making changes unless necessary.
Build for easy iteration.
Don’t reinvent the wheel every time changes to your company’s organization tree are made! Create a role hierarchy in Salesforce that stands the test of time and constant change by making it easy to adjust.
In the example above, a new level of management for the sales team in Europe would only involve adding a role called ‘Sales - EUROPE - Second Line Management’. What if your company is expanding its sales team into a new global region? You already have the blueprint and it’s no sweat to include another branch! This means minimal administrative work for you and more time to keep working through the never-ending list of requests.
Use standardized names.
In Salesforce, name standardization makes everything easier and a little less cluttered. Especially if you’re already standardizing opportunity names or workflow names, why not standardize your role names?
In the example above, the name standardization not only makes the roles easy to find, but also makes it incredibly simple to reference in other parts of Salesforce such as validation rules or reporting. You are able to easily reference department, region, or management level in logic without worrying about outliers and special cases.
Keep visibility in mind.
Although there are other permissions that can be set based on role, the one that I like to focus on the most is related to dynamic dashboards. If you’ve ever built a dynamic dashboard in SFDC, you know that in order for a user to view a dashboard as another user, they need to be above them in the role hierarchy. If your role hierarchy in Salesforce is too sprawled out or too difficult to keep up to date, you won’t be able to use dynamic dashboards effectively because the visibility levels will be incorrect.
In the example above, a user in the role of ‘Sales - AMER - Third Line Management’ will be able to see the dynamic dashboard in the eyes of all of the users below them with access to each representative's current state of their business. When building out a role hierarchy, I like to ask myself: Which users would need visibility into which other users’ work? If they don’t need to see anyone else’s work, then don’t put them higher in the hierarchy than they need to be!
Using these guidelines, you will be able to build a Salesforce role hierarchy structure that is sustainable. Don’t waste your time on constant adjustments to the role hierarchy — you have so much else to do! Instead, build something simple that lasts and allows for mindless changes.
Komentarze