Typing four hundred restaurants into a web form is not a plan. Import takes two kinds of file — stores and people — and both go through the same two-step: validate and preview, then commit.
- Choose whether you're importing stores or people, and paste or upload the file.
- Read the preview. It shows exactly what will be created, what will be updated, and every row it could not understand — with the reason.
- Fix anything you want to fix and re-validate. Nothing has been written yet.
- Commit. Now it's written.
Column headings are matched flexibly — the usual variations on store number, name, address, region and market are recognized, so an export from your existing system generally works unedited. The preview tells you what it matched.
For people, each row is a name, an email, a role and a territory. The role must already exist. Imported people receive alerts immediately and pick up their access when they first sign in.
| File | Available on | Why |
|---|---|---|
| Stores | Any plan with more than one site | Getting twenty restaurants in shouldn't mean typing twenty forms. Store contacts — a name, email and phone per store — are columns in this file, so a small operator can set up alerting entirely from a spreadsheet. |
| People | Plans with roles and territories | Every row needs a role and a territory to land in. On a plan with a single user there is nowhere to put them, so the option isn't offered rather than accepting a file that could only fail. |
The preview also checks the file against your plan's site limit, so a spreadsheet with more stores than your plan holds is caught before you commit rather than at the last button. If that happens, deactivating stores you've closed frees their places and keeps their history.
Read next: Adding people →Read next: Plans and what each one includes →