Hierarchies Basic Overview

About Hierarchies

Hierarchies provide a way for you to upload your organization’s employee structure into Qualtrics. They are a key feature in Employee Engagement projects, and setting one up correctly ensures the dashboard will display data by manager or unit.

Hierarchies can be added to Engagement and CX dashboards, but not Lifecycle or Ad Hoc Employee Research projects.

Static vs. Dynamic Hierarchies in CX Dashboards

In order to add an org hierarchy to a CX Dashboard, the dataset needs to contain the users’ unique identifiers. If you are uploading data into an Imported Data project, this is as simple as including a column with each user’s unique identifier in your CSV file.

However, if you are working with a survey project, you need to make sure the correct information is pulling into the survey before you can map it to the dashboard. There are 2 ways to do this.

Static Hierarchies

Static hierarchies allow you to add the hierarchy information directly to the survey response data as additional embedded data. This means that if adjustments are made to the hierarchy after data is collected, the hierarchy updates will only be reflected on future response data, since the hierarchy information is added to the response at the time the survey was taken.

To learn more, see Static Hierarchies.

Dynamic Hierarchies

Dynamic hierarchies allow you to link the hierarchy to the dashboard data, not the survey response itself. As a result, if the hierarchy changes, it will be reflected in the dashboard data.

Hierarchy information is linked with the response by matching a unique identifier in the response to a unique identifier in the hierarchy. Hierarchy information is then matched to the dashboard data. Any time the hierarchy is updated, it will automatically match to the dashboard data, allowing for dynamic updates.

In order to implement dynamic hierarchies, first make sure that the response contains a unique identifier that matches the unique identifier of a user in your hierarchy. See Dynamic Hierarchies to learn more.

Once your responses contain unique identifiers, follow the steps to add an org hierarchy to a CX Dashboard.

Choosing the Best Hierarchy for Your Data

The two primary types of hierarchy are Parent-Child (CX|EE) and Level-Based (CX|EE). 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 (CX|EE) are the most commonly used kind of hierarchy in Engagement projects, and are generally simpler to set up. 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 (CX|EE) are more commonly used in CX Dashboard hierarchies. They 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.

How Hierarchies Are Generated

Interested in how Qualtrics builds a hierarchy behind the scenes? When you upload your participant file (CX|EE), each row represents a different employee. As Qualtrics goes down the list, each employee is identified, and information attached to them (such as the manager, org unit, level, and so on) is used to figure out what unit they belong to in their organization.

1. We create a unit for manager i205, and put Jane inside it.
2. As we go further down the file, we see employee i205 is named Barnaby Smith. Now we know the unit Jane belongs to is run by Barnaby, so we can rename “unit for manager i205” accordingly to “Barnaby Smith.”
3. Furthermore, we can see who Barnaby’s manager is, and use this information to place the unit he manages and the unit to which he reports into the appropriate positions in the hierarchy.

The file does not have to be written in a particular order, e.g., from lowest to highest employee. Qualtrics will piece the hierarchy together as it goes down the list of employees in the file. What’s most important is that all the necessary employees in the hierarchy are present, and there isn’t any circular logic to the chain of command (e.g., Barnaby’s manager can’t be Jane if he is already Jane’s manager).

Additional Hierarchy Types

In addition to Parent-Child and Level-Based hierarchies, there are two more kinds of hierarchy that are much more rarely used, but may suit the needs of your project.

1. Skeleton Hierarchies: This option is best if you don’t know (or don’t want to expose the identities of) direct reports, but you do know your managers. This hierarchy is very different from Parent-Child and Level-Based because it is structured around a list of managers and the units they run, instead of a list of all employees and the units they report to.
2. Ad-Hoc Hierarchies (CX|EE): Ad-Hoc hierarchies often seem easier because you only need the bare minimum of participant information to start. However, the benefit of Parent-Child and Level-Based hierarchies is that after you create your detailed file of participant data (CX|EE), all you need to finish your hierarchy is to flip a few switches. On the other hand, Ad-Hoc hierarchies require that you manually place every single participant into the correct hierarchy unit, and manually configure all the managers and units. We generally don’t recommend this method, except with very small participant lists.

FAQ