Import people

Typing in a few hundred people is nobody’s idea of an afternoon. The People page takes a CSV, and re-importing the same file later updates what’s already there rather than duplicating it.

The file

A header row is required, and headers are matched case-insensitively with surrounding spaces ignored.

Column	Required	Notes
`email`	Yes	Also the identity key — see below.
`name`	Yes	Full display name.
`title`	No	Free-text job title, distinct from the structured role.
`department`	No	Free-text grouping.
`company`	No	Free-text company name — the value match expressions see as `company`.
`location`	No	Free-text office or location — the value match expressions see as `location`.
`roleattribute`	No	Pins the person’s Role as an override, matched to an existing role by name. Also accepted as `role`.
`levelattribute`	No	Pins the person’s Level as an override, matched by name. Also accepted as `level`.
`locationattribute`	No	Pins the person’s Location attribute as an override, matched by name.
`companyattribute`	No	Pins the person’s Company attribute as an override, matched by name.
`photourl`	No	Link to a profile photo, shown in the org chart. Also accepted as `photo_url` or `photo url`.
`manageremail`	No	The manager’s email address. Also accepted as `manager_email` or `manager email`.
`startdate`	No	Also accepted as `start_date` or `start date`.
`enddate`	No	Also accepted as `end_date` or `end date`.
`groups`	No	The person’s group memberships — see Groups below. Also accepted as `group`.

Columns you don’t need can be left out. Rows missing an email or a name are skipped.

Most files need only the text columns. A person’s role, level, location and company are derived from those fields when the row is saved, so a file like this is complete:

email,name,title,department,company,location,manageremail,startdate
[email protected],Priya Nayar,Principal Engineer,Platform,Example Ltd,London,[email protected],2021-03-01
[email protected],Tom Abara,Engineer,Platform,Example Ltd,Remote,[email protected],2023-09-11
[email protected],Dana Okafor,VP Engineering,Engineering,Example Ltd,London,,2019-06-24

Add the …attribute columns only where you want to pin a value the rules wouldn’t produce:

email,name,title,department,company,location,roleattribute,levelattribute
[email protected],Priya Nayar,Principal Engineer,Platform,Example Ltd,London,,
[email protected],Sam Kaur,Engineer (acting lead),Platform,Example Ltd,London,Manager,Lead

Priya’s blank cells leave her attributes derived; Sam’s pin two overrides.

Importing

Go to People under Configuration.
Choose Import CSV, select your file, and decide whether to let the import create roles, levels, locations, and companies it doesn’t recognize (on by default — see Attributes below).
Select Preview. Nothing is written yet — Resorcerer parses the file and shows what it would do: how many people will be created and updated, which attributes will be created, and which values don’t match anything and will be left as-is.
Review the preview, then select Confirm import to apply it, or Back to change the file or the create-missing-attributes option first.

Email is the identity key

People are matched on email. An address already in the workspace updates that person; a new one creates them.

This is what makes the import repeatable: export from your HR system on whatever cadence suits you and import the same file again. Promotions, moves, and new joiners all land, and nobody is duplicated.

It also means an email typo creates a second person rather than correcting the first. If that happens, delete the duplicate — deletions are reversible, and any position they occupied simply becomes vacant.

If any of your models are live, confirming an import also starts a live model recompute: every joiner, leaver, move, and attribute or manager change the file makes to someone in a live model’s scope turns up as a sync proposal on that model, ready to review in its Merge view. Nothing in a model changes until you apply it — unless you’ve turned on auto-accept for that kind of change.

Attributes

Role, level, location and company are normally derived from each person’s fields by the match expressions on the Roles, Levels, Locations and Companies pages — see Match people to attributes. An import fills the fields; the rules do the rest.

The roleattribute, levelattribute, locationattribute and companyattribute columns are for the exceptions. A value there is matched by name — ignoring case and surrounding spaces — against records that already exist, and the match is pinned on that person as an override: the rules won’t touch it until someone sets it back to automatic.

Create missing attributes (on by default in the UI) controls what happens when a value in one of those columns doesn’t match anything:

On — a new attribute is created with that name. New levels are ranked after every existing level, in the order their name first appears in the file, so set ranks deliberately afterward if the import order doesn’t reflect where they actually sit. New companies are created as regular (non-contractor) companies.
Off — the value is left unmatched: the row is reported in the preview and the import summary, and the person’s existing attribute is left untouched — a value that no longer matches anything never blanks out data you already have.

Either way, an empty cell is different from an unmatched one. A blank roleattribute cell means derive it: any override that person had is released and the rules decide their role. An unmatched value, by contrast, leaves whatever the person already had.

The API defaults create missing attributes to off, so existing scripts against the REST or GraphQL import endpoints keep behaving exactly as they did before this option existed — only the UI opts in by default.

Groups

The groups column sets which groups a person directly belongs to. Separate multiple groups with ;, and write a nested group as a /-separated path from its top-level ancestor down to it:

email,name,groups
[email protected],Priya Nayar,Engineering/Platform
[email protected],Dana Okafor,Engineering;Sales

Priya lands in the Platform group nested under Engineering; Dana lands in both the top-level Engineering and Sales groups. Matching is by name, ignoring case and surrounding spaces, scoped to each segment’s parent — a Platform group nested under Engineering is a different group from a Platform nested under Design, so a one-word Platform cell only matches a top-level group with that name.

The groups column has three states, and it matters which one a given file is in:

Column absent from the file entirely — every touched person’s existing group memberships are left exactly as they were. A file with only email,name,title columns, for example, can never change anyone’s groups, no matter how many rows it updates.
Column present, cell blank — that row’s person has every group membership cleared. Unlike the attribute columns, a blank groups cell isn’t a no-op; it’s an explicit “remove from all groups.”
Column present, cell has a value — that row’s person’s memberships are replaced with exactly what the cell resolves to (not merged with what they had before).

In other words, memberships are only ever touched when the file actually mentions groups for that row — omitting the column is always safe, but once the column exists, every row in it (including blank cells) is authoritative for that person’s group membership. This is different from department, company and location, which overwrite unconditionally whenever the column is present, and different again from the no-clobber behavior of roleattribute and friends. A person’s group memberships are edited by hand as freely as any other field, even on a person otherwise managed by an integration — see People and attributes.

Create missing attributes applies here too, one group at a time along the path: with it on, any group a path names that doesn’t already exist is created (nested under its parent, if it has one); with it off, a path with any missing segment resolves to no group at all — the whole path is reported once as unmatched in the preview and import summary, and no membership is asserted for it, rather than partially matching whatever ancestors do exist.

When something goes wrong

Rows are processed individually, and problems are reported per row without stopping the import: a row missing an email or a name is skipped, as is one whose end date falls before its start date. Dates that can’t be read are left blank. An unmatched roleattribute, levelattribute, locationattribute, or companyattribute value is reported the same way when create missing attributes is off — see Attributes — and so is an unmatched groups path, see Groups.

Because preview runs this same processing without writing anything, it’s a safe way to catch problems — misspelled attribute names, malformed dates — before they touch your data. If the file’s groups column (blank cells included) would leave any touched person with fewer group memberships than they currently have, the preview also surfaces a line like “12 existing group membership(s) will be removed” — so clearing memberships is never a silent side effect of confirming the import.

The exception is your workspace’s people allowance. If the file would take you past it, the import is cancelled before anything is applied and tells you how many new people it would have added — rather than loading half a file and stopping. Only genuinely new email addresses count toward that check; rows that update someone already in the workspace cost nothing.

Managers

manageremail links a person to their manager by email. Forward references are fine — you don’t have to order the file so managers come first.

This reporting line is between people and describes your organization as it is. It’s separate from the reporting lines inside a model, which are between positions. See Units and slots.

Preview doesn’t assign managers — it can’t detect a reporting-line cycle without actually writing the people it would create, so manager assignment happens only when you confirm the import.

Exporting

The Import / Export page handles the other direction, and works at a larger grain: pick which models to include, and which reference data — roles, levels, locations, companies, cost profiles, people, labels, composition rules, checklist templates — to carry with them. A model’s units carry their readiness checklist states. Archived models can be exported too.

Snapshots aren’t in that model list. To export one, open the model it was taken of, go to its Snapshots tab, and choose Export on the snapshot’s row. You get the same file the Import / Export page makes for a single model.

Use it to move a workspace’s configuration somewhere else, or to keep a copy outside Resorcerer.

Individual model views export too: the Slots view will give you a CSV of exactly the positions your filters have selected, and the People view a CSV of the people they have selected, with the units each person is assigned to.

People and attributes — what the fields mean.
Match people to attributes — how role, level, location and company are derived.
Build your first model — putting the people to work.
Integrations — keep people current automatically instead of re-importing a file.
Keep a model live — turning people changes into reviewable proposals on your models.