The roster spreadsheet

There is no mandatory template

First, because it saves work: you do not have to rename your columns. The importer reads whatever headers your file has and proposes a mapping by name —«Cargo» → position, «Depto» → location— and you confirm or correct it on screen.

Nothing is imported on the heuristic alone. The suggestion is a suggestion; the mapping that counts is the one you confirmed.

The file

A 5 MB .xlsx is hundreds of thousands of rows: the limit will not bother you.

The fields

There are no demographic columns, and that is not an oversight. Sex, age and tenure are not imported from the roster: they originate in the questionnaire itself, at response time. That separation is what makes it possible to segment by demographics without ever being able to link a response to a person. If your spreadsheet has them, they simply do not get mapped.

Accepted date formats

2026-08-16      (YYYY-MM-DD)
16/08/2026      (DD/MM/YYYY)
16-08-2026      (DD-MM-YYYY)

Location: one column or several

If your file has the full location in one column («North Store»), map that one.

If it is split —Country, Region, Store, Department in separate columns— you can map them all to the same field. The importer combines them to identify the node.

Matching against the tree

The text in your spreadsheet has to correspond to nodes that already exist. «North Region» in your file against «North» in the tree is a normal case, and you resolve it on screen: the importer shows you the values it could not place and you pick the node.

It never guesses silently. An unresolved value is reported; no node is created and nothing is assigned to the closest match. The tree's names live in the tree.

An employee can only live in a LEAF node —one with no children. If your spreadsheet sends people to an intermediate node, those rows are rejected. It is consistent with what the tree means: a person works in a concrete place, not in a category.

Roster statuses

Every person is in a status, and the statuses are yours: a new account comes with five (active, holiday, sick leave, inactive and resigned), but you can rename them, retire them or add the ones you actually use, like «Unpaid leave». They are defined under Configuration → Payroll → Statuses.

Each status has one checkbox that decides everything else: «Can receive surveys». Anyone in a status with it checked goes into the sample of your studies and counts toward your plan's people cap; anyone in a status without it stays out of both. It is a single criterion on purpose: what is not billed is not surveyed. A new status is born without the checkbox, so nobody receives a survey until you decide it.

Two statuses also carry a role:

• «For new people» is where a person added without a status lands, and the one the import uses when the column is not mapped.
• «For people who leave» is where anyone missing from the file goes in Sync mode. It cannot have the checkbox checked: if it did, syncing would remove nobody from anything.

In the spreadsheet, the status column must carry the name of one of your statuses. A value that does not match is reported in the preview as a row with an error; no status is created and no closest match is picked.

Changing a status's checkbox does not reinterpret a study that already generated its sample: it applies to the ones you set up from then on. There is a second criterion for entering the sample, the minimum tenure, which lives under Configuration → General; see The four steps before your first study.

The two modes

Add — Adds whatever is in the file. Leaves anyone not present alone.

Sync — Makes the roster match the file. Anyone absent moves to the «For people who leave» status, never deleted: participation in past studies references those people, and deleting them would break the history.

The three steps

1. Analyze — Reads the headers and proposes the mapping. Does not validate data yet.

2. Preview — Validates everything without writing: valid rows, failing rows and why, unmatched locations. This is the point where you can still cancel.

3. Execute — Writes. It is all or nothing: if a single row is invalid, none are persisted.

Being transactional is what makes the preview safe. You cannot end up with half a roster loaded and half not; either the whole file went in, or nothing did and you can fix it and retry.

Common errors

Before importing

Build the tree first. The importer matches against existing nodes, so uploading the roster before the structure exists turns every row into an unresolved location. See The org tree.