-
Customer Experience -
Employee Experience -
Brand Experience -
Product Experience -
Core XM -
Design XM
Hierarchies Basic Overview (CX)
What's on This Page:
About Hierarchies
Hierarchies provide a way for you to upload your organization’s employee structure into Qualtrics. Setting one up correctly ensures that tickets will be properly escalated.
Attention: Like the rest of the User Admin tab, hierarchies are brand-wide. That means that when you create hierarchies in your Dashboards project:
- Those same hierarchies will be available in all Dashboards projects in the brand.
- Those hierarchies will be built using information from all the users in the brand. That means every user will be placed in the hierarchy based on an Employee ID, Manager, or Level, depending on the type of hierarchy you are building. If this data is blank, the user will not be excluded from the hierarchy, but instead will be relegated to a unit called “Unknown Manager.”
Choosing the Best Hierarchy for Your Data
The two primary types of hierarchy are Parent-Child and Level-Based. Both Parent-Child and Level-Based hierarchies can generate your organization’s structure and identify managers based off a list of employees. However, the type of hierarchy you choose has less to do with your company’s organizational structure and more to do with the data most conveniently available to you.
Parent-Child vs. Level-Based Hierarchies
Parent-Child hierarchies work best when your HR data for each employee includes a unique ID and the ID of their manager.
Level-Based hierarchies can be a good option if your HR data includes each level the employee reports to, from the top of the hierarchy all the way down to where the employee sits. With Level-Based hierarchies, you don’t necessarily have to know who the employee’s manager is; you just need to know the chain of command for each employee you’re including in the project. This data format is often more common with companies that organize employee data by distinct levels, location, or functional breakout.
One advantage Level-Based hierarchies have over Parent-Child ones is when you are running a project with an incomplete hierarchy. For example, you may be running a project with only a few teams, not your entire company. Parent-Child hierarchies determine the chain of command by placing every single employee and every single manager into an organizational unit; if you are missing employees, you may end up with broken or displaced units. Level-Based hierarchies, on the other hand, define each employee on a row with their entire reporting line up to the top. It’s ok if you’re missing a few people because the chain of command is still there.
On the other hand, when it comes to defining managers, Parent-Child is much simpler to build. You can also identify managers and the data that rolls up to them in a Level-Based hierarchy, but you need to add an additional column to your data to do so, and managers must be coded as far down as the unit that they manage.
Parent-Child vs. Level-Based Hierarchies: At a Glance
| Parent-Child | Level-Based | |
| When recommended: | When your HR data is formatted so each employee has a unique ID and their manager’s unique ID saved | When your HR data is organized more by location or functional breakout |
| Required for setup: | Employee ID & Manager ID | Cascading levels of organization structure |
Using CX Hierarchies
CX hierarchies currently have two uses.
- In CX Dashboards themselves. Use hierarchies to control the information users see in CX Dashboards. See Adding Org Hierarchies to CX Dashboards for how to get started. Don’t forget to assign your users to roles with hierarchy permissions.
- In ticketing. Use hierarchies to control how tickets are reassigned.