What are Hierarchy Roles?
Hierarchy roles allow organizations to assign specific actions and/or responsibilities to specific users for specific locations only.
Hierarchy roles behave similarly to groups in the sense that a hierarchy role is essentially a set of users that have common responsibilities/settings. However, with groups, each user in the group will have the same responsibilities/settings for each hierarchy node they have access to. Hierarchy roles allow users to have different responsibilities/settings for the hierarchy nodes they have access to.
What can I do with Hierarchy Roles?
There are two primary cases where our customer's implement hierarchy roles:
1) Allow users to have wider access/visibility to data from additional hierarchy nodes (see and audit all locations in my network for example) while limiting the notifications/case and followup assignments to specific locations (the locations I manage).
2) Allow cases to be automatically assigned, via triggers, to the user(s) with a particular role on the hierarchy node the action is associated with.
What Hierarchy roles are available?
Currently, there are several hierarchy roles available, including:
- User (general)
- General Manager
- Location Manager
- Area Manager
- District Manager
- Division Manager
- Territory Manager
- Regional Manager
- Maintenance Manager
- HR Manager
Where do I add Hierarchy Roles?
Hierarchy roles are added directly on hierarchy nodes. Navigate to account settings -> organization settings -> hierarchy.
For more information, check out this article.
Can I have some examples?
Of course!
Use Case 1: Allow users to have wider access/visibility to data from additional hierarchy nodes (see and audit all locations in my network for example) while limiting the notifications/case and followup assignments to specific locations (the locations I manage).
Example:
Let's imagine an organization where all location managers are required to perform safety audits at their peer's locations.
Each 'Location Manager' would be assigned the 'Location Manager' role on the hierarchy nodes they manage. Each user would also be assigned a 'User' role on their peer's hierarchy nodes.
Trigger notifications that send emails completed audits for this organization would be set up to send a record email to the 'Location Manager' role (rather than a group) specifically so that each user is only notified about the activities at the locations they have the 'Location Manager' role on.
Use Case 2: Allow cases to be automatically assigned, via triggers, to the user(s) with a particular role on the hierarchy node the action is associated with.
Example:
Let's imagine an organization where cases are created each time a survey is submitted where the respondent (a detractor) wishes to be contacted by the manager.
Each user would be assigned the 'Location Manager' role on the hierarchy nodes they manage.
A trigger would be set up to create a case, and assign that case to the 'Location Manager' manager role. This means that for whichever hierarchy node the survey response was submitted against, all users given the 'Location Manager' role on the node would be assigned to the case.