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:
Export first. This gives you both the current state and the exact column format the import expects.
Edit the exported file rather than building one from scratch.
Test with a few rows. Confirm they landed as intended before committing the rest.
Import the remainder.
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.