Organization management
Organizational hierarchy maps the company's organizational structure within Medallia Experience Cloud. For EX, employee feedback — coming from survey responses — is tied to the lowest levels of the hierarchy, to later be used in reports, alerts and reports.
Organization file
The Organization file is imported to Experience Cloud, together with the Feedback invitation file and the Users file.
The Organization file require three categories of data fields:
Unit name and identifier — These are mandatory fields to create employee units. The identifier should be unique to the employee. Employee ID is the most commonly used identifier.
Roll-ups — Multiple types of roll-ups such as org structure ("who reports to who"), cost structure ("who pays for who"), geography/location, brand/company, department, job category, etc. For more information, see Hierarchies.
- Additional information — Additional information related to the employee. This may include:
Fields to condition survey elements and segmentation, such as hire date/tenure, date of birth/age, compensation grade, salary/pay, gender, race, whether or not the employee is a people manager.
Fields to filter reports, for example to view responses from female employees in Software Engineering only.
Fields for benchmarking. Note that benchmarking can only be performed based on information in the org data file.
Fields for ranking, such as ranking all departments based on scores.
Fields for data access.
Any other field such to enrich reports and exports.
Feedback invitation file
Consider the following best practices:
Include time-based segmentation fields (such as Age, Tenure, Time in role) in the file in addition to the organization file. The value of these segments should always be stored at the time the survey is created, since not doing so may lead to incorrect interpretation of the data. For example, surveys submitted two years ago should be associated with the employees’ tenure at the time of the survey rather than the current tenure of the employees. If using a dynamic hierarchy setting, ensure these fields are included in the invitation file and stored as Event fields to preserve the “history” of the data. Even if using a persistent hierarchy setting, including these fields in the invitation file is helpful in case the client changes their mind later.
For Employee Engagement and Journeys & Moments app surveys where a transaction ID is not available, construct unique identifiers in the Invitation Importer per record for duplicate checking. Use a combination of unique employee information (such as Employee ID/Email), Date, and survey type to construct the unique identifier. For example, judy@orion.com_20210101_rel.
Users file
Consider the following best practices:
- Include one common user file for all programs (CX and EX). Clients may prefer to send separate data files for CX and EX as they could be based on different data sources. Discuss the following implications with them before aligning on a design:
The file processed last may overwrite the roles an/or data access provided by the files processed earlier.
Difficult to indicate which role should be a user's primary role (between CX and EX roles) if they are in separate files.
More tricky to process the user file on Sync mode to deactivate accounts that are no longer active. Use the correct syncScopeRoles attribute in the Importer to choose the scope of roles to be included in the Sync process.
Unit types
Choosing the right unit type is critical to building a scalable solution. Select among the following units:
-
Employee — Employees as units is recommended for most employee programs. Feedback is tied to the employee providing feedback (for Employee engagement surveys), or the employee tied to the journey/transaction (for Employee Journeys and Moments and Services surveys).
A single hierarchy can be used for all EX programs. Scale assessment may be needed for large programs (> 100k employees).
-
Team — Team as units. Feedback is tied to the team the employee providing feedback belongs to.
Teams as units is recommended for very large programs (>400k employees) for better system performance.
-
Locations — Feedback is tied to the location the employee providing feedback belongs to.
Locations as units is recommended for location-based businesses (for example, retail, hospitality) where data is not available or reliable at the employee level. In such cases, CX and EX programs can share the same org hierarchy. Very large location-based businesses (>400k employees) may also use locations as units instead of employees as units.
Organization hierarchy settings
Organization hierarchy settings, also known as Org hierarchy filters, identify the instance of Unit group information to use in report filters. When org hierarchy settings is enabled, the filters use the persistent data stored with the record. Otherwise, when disabled, the filters use the org hierarchy information currently associated with the unit. For more information, see Org hierarchy filtering.
| Persistent | Dynamic (Org sync) |
|---|---|
| Traditional approach. Not recommended for primary roles. | Experience Cloud approach. |
| Feedback is always tied to the Unit groups the unit belonged to at the time of survey creation (that is, it is persistent). | Feedback is always tied to the Unit groups that the unit currently belongs to. |
| Historical scores do not change when there are organizational changes. | Historical scores change when there are organizational changes. |
| Known as As was, History follows the manager, etc. | Known was As is, History follows the employee, etc. |
For example, John was in Engineering in 2020 reporting to Scott. He moved to Product Management in 2021 reporting to Sarah.
Persistent setting — John’s feedback from 2020 remains with Engineering and with Scott. John’s feedback from 2021 rolls up to Product Management and to Sarah.
Dynamic setting — John’s feedback from 2020 and 2021 roll up to Product Management and to Sarah.
One of the most important implications of the Org Hierarchy setting is data access and historical data trending. Depending on the setting chosen, managers may lose or gain access to historical data during changes in the organization.
Data access
You may use a hidden Unit group to control data access. In the following example, Org Level 1 (Kimberly S.) has access to the entire organization and does not require a data access to the Unit group. Using this Unit group for data access, Org Level 2 (Mike P.) can see feedback from his direct reports in Org Level 3 (Rick T.) and indirect reports in lower levels (Elizabeth K).
