One of the most misunderstood and underused feature of Salesforce is the Role Hierarchy.
Without a well-designed Salesforce role hierarchy, companies are likely to have the following problems:
– Salesforce sales forecasting does not work
– Private sharing model does not meet company needs
– Managers can not easily see what subordinates are working on
– Chatter license holders cannot see or follow the records they care about
– Chatter license holders can see and follow records they should not have access to!
While there are other ways in Salesforce to work around these issues, for the purpose of this blog post we will focus only on the Salesforce role hierarchy.
The increased use of Chatter licenses, which is allowing people who’ve never used Salesforce CRM to begin to use Salesforce, creates a significant need for the organization to create the appropriate role hierarchy to make sure that Chatter does not result in employees accessing information that they should not have access to.
Thinking about security for Chatter is no different than thinking about security for any data in Salesforce: Chatter observers all permissions.
You can not follow or see records that the role hierarchy or sharing settings do not allow you to access.
The role hierarchy is best looked at like a tall tree with information flowing up from the bottom to the top. The hierarchy can have many branches and many people on one or each branch, or it can have just a few branches with only one person per branch. Like a tree, your role hierarchy is a living object that will continue to evolve as your company grows and changes.
As an example, let’s look at a company that sells and supports software and hardware. They would have different branches for sales and support. Inside those, they may have more branches for the different types of hardware (keyboards, hard drives) and software (productivity, entertainment). We could even go further and say they have different locations around the world or the country. As you can see, the hierarchy can get large rather quickly.
The first step is to gather your leadership team and draw up how you would like your hierarchy to look.
Unless your company is relatively small, you will usually find that each person in your leadership team will have a slightly different idea of how the hierarchy should be laid out. This is why it is best to hash it out so everyone has a clear understanding of what departments report to whom and whether access to records should flow across roles or stay within the role.
Generally, roles will control the level of access that users have for your data. People at any given role can edit, view, and report on all data owned by or shared with users below them in the role hierarchy.
It is important to keep this in mind when designing your own hierarchy so that you do not accidentally expose data or lock someone out of data that they need to do their job.
When designing your role hierarchy, every user must be assigned a role, or their data will not display in forecast roll-ups, opportunity reports, and other displays based on or filtered by roles. You must have your role hierarchy set up before setting up Salesforce sales forecasting as the forecast hierarchy pulls directly from the role hierarchy.
Since the access to the data and records rolls up, users that require access to all of the data in your organization should be placed at the top of the hierarchy.
If you place a system administrator lower in the hierarchy, and then they run a forecast or opportunity report, the report will only return data from that point in the hierarchy and anyone that reports to them. They may be able to view any record but they will not be able to report on any records owned above them in the hierarchy.
Your role hierarchy does not need to match up with your org chart exactly, although most do.
Think of your roll hierarchy as a representation of data access levels that an employee or group of people need.
The hardware support team in Denver will most likely not need access to sales figures of software in Seattle. On the other hand, the Denver support manager may need access to the Seattle hardware and software sales numbers to forecast the support work load associated with Seattle sales.
The role hierarchy in Salesforce.com is dynamic. It will evolve as your company does.
