Skip to main content
  • 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 (CX)

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: CX Hierarchies are only available to CX licenses with ticketing included. If you’re interested in this feature, reach out to your Account Executive.
Qtip: CX Hierarchies and EX Hierarchies are very similar, but have some key differences. If you are an EX client, please see Hierarchies Basic Overview (EE) instead.

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:

  1. Those same hierarchies will be available in all Dashboards projects in the brand.
  2. 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 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 Customer Experience products. In the employee data file, Barnaby has Customer 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.

Parent-Child vs. Level-Based Hierarchies: At a Glance

Parent-Child Level-Based
How often used: Used most frequently Used sometimes
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

Ticket Escalation Using Hierarchies

Right now, CX hierarchies are only used in a new Ticket Workflow. When you select the Re-Assign Ticket action, you can choose the new ticket owner by Org Hierarchy.

Ticket Workflows window opened. Scroll down through new workflow in re-assignment mode to see that the ticket can be reassigned by hierarchies in step 3

From there, you select the hierarchy you use in this workflow, then select the unit that should be forwarded the tickets. You can choose how many levels above the ticket owner’s unit the ticket should be reassigned to:

  • Parent Unit (1): If a ticket meets the workflow’s conditions, then it will be reassigned to someone in the unit above the current ticket owner. This kind of workflow is ideal if a certain status or age signifies that a more senior team at your company must follow up with the ticket.
  • Grandparent Unit (2): You will also be able to select the unit directly above the parent unit. This is useful if some of your company’s units are very small, or if you want larger groups of employees working towards a common goal.
Example: Let’s say the ticket owner belongs to the Web Design team. The Web Design Team belongs to the Digital Marketing department – that makes Digital Marketing the parent unit of Web Design. The Digital Marketing department sits under the rest of Marketing – that makes Marketing the grandparent unit of Web Design.