Anatomy
1 UPLOAD 2 MAP COLUMNS 3 PREVIEW & VALIDATE 4 RESULT
┌──────────┐ Your column → Field Row 1 ✓ Riverside… ✓ 284 created
│ drop a │ "Client" → Client Row 2 ✓ Kestrel… ✓ 12 updated
│ file │ "Amt" → Amount Row 3 ✗ Amount "n/a" ✗ 4 skipped
└──────────┘ "Due" → Due date is not a number ↓ download
"Notes" → (ignore) the 4 rows
The four steps are not decoration — each one prevents a specific failure:
- Upload accepts what people actually have, including a paste.
- Mapping is shown and correctable. A silent guess is how a phone number column ends up in the reference field.
- Preview shows the converted values, so people check the interpretation rather than the input.
- Per-row results, with the failures downloadable.
Why it works
It removes the single largest barrier to adopting an internal tool. Data that already exists is not a nice-to-have — it is the business, and a system that cannot accept it is a system that will run alongside the spreadsheet forever.
The per-row failure model is what makes it usable in practice. An all-or-nothing import of three hundred rows fails on row 214 and gives back nothing, so the person fixes one cell and waits again. Importing 296 and handing back 4 to fix converts an afternoon into five minutes.
The parts everyone skips
- The conversion preview. People do not check raw text; they check meaning.
Showing
14/07/26is useless — show that it will be stored as 14 July 2026, and the day-month ambiguity gets caught before it corrupts three hundred rows. - Match behaviour. Whether an incoming row creates, updates or is skipped is the highest-consequence decision in the whole flow, and it is usually a hidden default.
- The downloadable failures. Without them, "4 rows failed" means re-deriving which four from a file of three hundred.
- Undo. An import is a bulk action with a large blast radius. It is exactly the case where confirmation is warranted, and reviewability afterwards matters more than the dialog.
Getting it wrong
- All-or-nothing. The defining failure of bad importers.
- Silent column mapping, producing a plausible-looking import that is wrong in one column.
- Errors reported without row numbers, so the person cannot find them.
- No preview, so date and number formats are discovered afterwards.
- Hidden update behaviour, quietly overwriting records the person expected to be created.
- Accepting only CSV, when everyone has .xlsx and converting is an extra step that loses formatting.
Exemplars
Stripe's product and price import shows the preview-and-map flow done carefully, because a mis-mapped price column has immediate financial consequences.
Airtable's import is the reference for match behaviour: choosing the key field and what happens on a match is an explicit step, not a checkbox.
Mailchimp's contact import is worth studying for the failure report — the skipped rows come back as a file you can fix and re-upload, which is the whole loop closed.
The extractable rule: an import is a conversation about interpretation, not a file transfer. Every step exists to show the person what the system thinks their data means, before it commits.