Skip to main content
Loading...
  • Customer Experience
    Customer Experience
  • Employee Experience
    Employee Experience
  • Brand Experience
    Brand Experience
  • Product Experience
    Product Experience
  • Core XM
    Core XM
  • Design XM
    Design XM

Hierarchies Basic Overview (EE)

What's on This Page:


Was this helpful?


This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

The feedback you submit here is used only to help improve this page.

That’s great! Thank you for your feedback!

Thank you for your feedback!


Qtip: This page describes functionality available to Engagement projects, but not Lifecycle or Ad Hoc Employee Research projects. For more details on each, see Types of Employee Experience Projects.

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.

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 are the most commonly used kind of hierarchy, 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.

Example: You have a spreadsheet of data. Each row is an employee. For each employee, there’s a column for their employee ID, and a column for their manager’s ID.

Level-Based hierarchies are not as popular, but 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.

Example: Barnaby is a member of the sales operations team. This team sits within the sales department, which in turn sits in the division that sells our Employee Experience products. In the employee data file, Barnaby has Employee Experience in the Division column, Sales in the Department column, and then Sales Operations in the next column.

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, 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.

Example: The first row of our file has information on the employee Jane Doe. We know her ID, which is i322, and her manager’s ID, which is i205.
  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: 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, 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