Steps for a stable setup
Guidelines to set up your programs for longevity, quality, and flexibility.
Make sure you follow these guidelines for system health and stability. Configure for peak performance.
-
Initial technical setup (fundamental architecture) — What you create at first login to ensure scalability and sustainability.
-
Ongoing technical infrastructure (repeated, continued action) — What system components to thread though all programs and configurations in the system.
-
Account health (ongoing monitoring) — What are the resources outside of the instance than ensure long term relationship and account health.
Initial technical setup
These are fundamental architecture principles: they cover the discovery, design, prototyping and readiness tasks to build for long term success. Check what you create at first login to ensure scalability and sustainability.
Org hierarchy
In this stage focus on context, syntax, and benchmarking.
Unit types
For every unit field, create a "Unit Type" value that best describes the unit in both an e-field (for example "e_digital_unit") and a Unit Group (for example "unittype_digital").
-
E-field unit type — This field should always be a descriptor field of the units being created, for example "e_b2b_account_unit". For this field:
-
The alternative set should always be "Unit".
-
The e-field should be mapped in the record creation auto importer with the same mapping as e_unitid
-
- Unit group unit type — To start, select the appropriate "Unit Class": Account, Location, Digital, Individual, Product, Event, and Other. For the unit group:
- It should be mapped in the org hierarchy auto importer with a constant value for all of the units generated.
Standalone unit architecture
For programs without a hierarchy structure, map all records to a single "static" or "standalone" unit. In order to facilitate user setup, you should look to still map this "static" unit to the same unit type structure that you would for a full hierarchy
Use the static unit naming convention below:
Name = [PROGRAM] Unit
Identifier = [PROGRAM]_unit (lowercase, with '_' for spaces)Org hierarchy filtering
Org hierarchy filtering (OHF) identifies the instance of the unit group information to use in report filters. When turned on, the filters will use the persistent data stored with the record when created (persistent). When turned off, the filters adjust when the org hierarchy is updated (dynamic).
For users assigned access to a unit group in the hierarchy, OHF will determine what historical data the user can see.
There are several considerations with Org hierarchy filtering:
-
View in reporting — For users who have access to all units, OHF affects what is returned when filtering on unit groups or viewing unit-group-level reports (e.g. Ranker).
-
Data quality — Data quality is also a key driver of whether you should turn on OHF or not. If data quality — of the hierarchy/invitation file(s) — is poor, leave OHF filtering off to avoid issues around incorrect roll-ups of data as a result of the poor data quality.
-
Implications — When OHF is disabled, any changes to the hierarchy are automatically reflected across all records. When OHF is enabled, updating the hierarchy historically can be more complex as the individual survey records need to be updated.
-
Program level — All roles within a program should have the same org hierarchy filtering settings.
See best practices for OHF based on unit type below:
| Unit type | OHF | Notes |
|---|---|---|
| Location | Org hierarchy filtering tends to be turned off for locations based hierarchies. This is so that managers can see the full history of their locations, to understand year-over-year (YOY) trends | |
| Location (franchise) | The exception to the rule is franchised locations. Franchised locations typically have OHF turned on as, while people might not specifically be included in the hierarchy, the location is associated with a owner/person who is responsible for the performance of the location (and possibly bonused/penalized based on their performance). Therefore, the user should only see scores for their tenure as owner of the location. | |
| Individual | Typically, org hierarchy filtering should be turned on for People hierarchies as users tend to only be responsible for the latest version of their team (from when that user took over) and may have bonuses tied to it. Therefore, it makes the most sense for users to only see data relevant to them ('their' scores), rather than the full history of the team (units) which would skew 'their' numbers. | |
| Account | Account Hierarchies should have OHF off since account managers rolling onto an account benefit from seeing the historical context of the account. | |
| Digital | OHF is not really relevant for digital hierarchies. Larger companies often have multiple digital units (properties) across different countries and brands, however, it's unlikely that these properties would move in the hierarchy. | |
| Event | As an events manager, you would only want to see the events that you had managed (especially if tied to compensation / bonuses). |
Benchmarking
On the unit groups screen, ensure the top level unit group "all [instance] units" is not checked to include in benchmarks. Benchmarks are determined by the units accessible to the user.
Field naming
Below are the recommended naming conventions for E-fields, Q-fields, and K-fields.
bp_" prefix. Do not use this prefix for manually created fields.Ongoing technical infrastructure
This section focuses on repeated, continued action to error proof your environment.
Sandbox and production
A sandbox is a copy of the MEC production instance to mimic the functionality of the instance. This is the location to configure projects prior to bringing them live in the production instance. Each project completed should follow the steps below:
