Preparing a User File to Make a Hierarchy (CX)

About Preparing a User File to Make a Hierarchy

When importing users to your CX Dashboard, there are a few important things to keep in mind. For example, every import will need the following columns:

• First Name: The user’s first name.
• Last Name: The user’s last name.
• Email: The user’s email address. This detail is the most important. Email can act as username for each user or as a way to remember which users already exist in the User Admin.
• Username: If your organization uses SSO, you must include a Username column. This column should contain the same information as the Email column, because the#brandId will be automatically added to the end.
• Language: This column is technically optional. However, if you choose to include this, you must be careful to capitalize Language as seen here, and enter the value for each user in language code

In addition, you’ll want to make sure that you’ve chosen the right hierarchy for your project, since this affects the User Attributes, or custom columns of user data, that you will include in your CSV/TSV file. For example, the Parent-Child hierarchy file should include columns for Employee ID and Manager ID, whereas the Level-Based hierarchy file should have different Level columns.

Preparing a File for a Parent-Child Hierarchy

Parent-Child hierarchies are the most commonly used kind of hierarchy. They are the best option if your HR data is formatted so you have a list of employees’ IDs and the managers each employee reports up to.

When you have finished building your file and are ready to build a hierarchy, see Generating a Parent-Child Hierarchy.

Required Metadata

There are two metadata columns you must include to create a Parent-Child hierarchy:

• EmployeeID: This is the employee identification of the participant. It is best to use the IDs your company’s HR department has internally assigned, rather than trying to make up new randomly generated IDs.
• ManagerID: This is the employee identification of the participant’s manager.

When adding Employee and Manager IDs, there are a few important things to keep in mind:

• Every participant must also have a unique Employee ID. Multiple participants cannot share the same ID.
• Every participant must have a manager. The only exception are the highest members of the company you include in your hierarchy (e.g., CEOs). Leave the manager column empty to show this person doesn’t report to anyone.
• An individual employee’s Employee ID and Manager ID columns should never be the same. Employees don’t report to themselves!
• Every Manager ID must link back to an employee. Any participant with a Manager ID that does not correspond to an existing Employee ID will be assigned to an Unknown Manager. Please note that once someone is assigned to an Unknown Manager, the members of the hierarchy below this person will also be broken. To fix this issue, you must manually fix the data and regenerate the hierarchy.
• Watch out for circular logic. If John Doe reports to Jane Smith, and Jane Smith reports to Joseph Miller, Joseph Miller cannot report to John Doe. You cannot manage your manager’s manager.

Optional Metadata

You can add any additional metadata that you wish when uploading your participant list. Anything from each employee’s birthday to their office locations can be included. However, there are two optional metadata that can help you format your Parent-Child hierarchy.

• Org Unit ID: Org Unit IDs help you identify the same team over time, even if the team’s name changes. It serves the same purpose as a unique employee ID, but for a unit instead of an employee.
  Qtip: Have different teams with the same name? Or, do you have separate sets of teams and managers reporting within the same division? You can reuse the same Org Unit Description by setting separate Org Unit ID fields. For example, one sales manager may run a team called Sales with an Org Unit ID of 001, and another manager may run a team called Sales with an Org Unit ID of 002.

  Org Unit IDs are also useful if a manager is over multiple teams. This means that if my manager is John Doe, but John Doe is the manager of Team A and Team B, I can specify to which team I belong with the Unit ID field.

• Org Unit Description: When creating your hierarchy, units will be automatically named for a manager. The Org Unit Description setting allows you to name your units based on names or descriptions of the units instead.

The Org Unit Description is essentially the name provided for the provided Org Unit ID, and will appear as the unit’s label in dashboards when filtering or breaking out by unit. The columns shouldn’t necessarily contain the same exact values, but while ID is numeric, Description is descriptive. For example, Org ID 2’s Org Unit Description may be European Division.

Preparing a File for a Level-Based Hierarchy

Level-Based hierarchies are 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.

When you are finished building your file and are ready to create a Level-Based hierarchy, see Generating a Level-Based Hierarchy.

Required Metadata

You will need a separate column for each level of your organization you wish to define. The last level filled for a participant indicates their place in the hierarchy. For those higher up, this usually means the first Level column is filled, but the rest aren’t.

Manager Metadata

If you’re interested in assigning managers to units in your Level-Based hierarchies, there are two different ways to do it.

• Manager: This column indicates whether the participant is a manager. The participant will be assigned as the manager of the lowest level he or she has listed. Most users use “yes” to indicate a manager, but you can also use “1,” “manager,” or any format you’d like, so long as you have one value in the column that indicates that the participant is a manager.
  Example: In the image below, the lowest level defined for Sammy Stanage is Level 1, where he is in a Customer Success role. The “yes” in his Manager column indicates he is manager over all of Customer Success. Meanwhile, Jeff Brown’s last level defined is Employee Experience within Engineering. This means that within Engineering, he is head of the Employee Experience level.
  
• Manager Level: Manager Level is a means of identifying managers by calling out the specific level they manage. In the previous example, the same value (“yes”) indicates whether or not a participant is a manager; for Manager Level, however, there are separate values for each level.
  Example: In the image below, Jeff Brown’s Manager Level is 2 to indicate he is manager of his Level 2 position in Employee Experience, not manager of his Level 1 position in Engineering.
  

Optional Metadata

Org Unit IDs: Org Unit IDs help you identify the same team over time, even if the team’s name changes. It serves the same purpose as a unique employee ID, but for a unit instead of an employee. You need to include as many Org Unit IDs as you do levels, so you can provide an ID for each level.

In the screenshot below, the units in Level 2 correspond to the column Org Unit ID 2. The Employee Experience engineering team is unit 201, and the Customer Experience engineering team is 224.

FAQs