Importing and exporting employees

You need: Employees — view to export, Employees — edit to import.

Exporting

Export produces a CSV of the employees within your brand and scope.

Two good reasons to export, beyond bulk editing:

• As a snapshot before a bulk change. It is your rollback, and takes seconds.
• To review. Reading a hundred records in a spreadsheet is faster than clicking through a hundred screens.

An exported file is no longer scope-filtered. It contains staff data, so treat it accordingly — see the same caution in Exporting data.

Importing

Import applies employee configuration from a CSV.

The sequence that avoids trouble:

1. Export first. This gives you both the current state and the exact column format the import expects.
2. Edit the exported file rather than building one from scratch.
3. Test with a few rows. Confirm they landed as intended before committing the rest.
4. Import the remainder.
5. Spot-check two or three people on the employee list.

Imports are not transactional

A failure partway through leaves earlier rows applied and later rows not. There is no rollback, which is why the export in step 1 matters and why you find out where it stopped before re-submitting.

Re-running a whole file after a partial failure may re-apply rows that already succeeded.

Backups

Employee configuration is covered by the backup system: exports are retained, and can be downloaded or restored — see Backups and restoring configuration.

Restoring an employee backup follows the employee permission, not a separate backup one. And as with every restore, it reinstates the snapshot wholesale: anything changed since, by anyone, is overwritten for the records it covers.

What import does not touch

Roles, scope and passwords are not part of employee configuration. Importing a hundred employees gives none of them console access — see Managing roles from the console.