Manual entry doesn't scale. When you need to load hundreds, thousands, or hundreds of thousands of rows into a datastore, the import tools take over. The platform supports CSV, Excel, and other file types via a configurable importer.
The Import Data button on a datastore (next to the New Record button) opens the import dialog. You upload a file, map its columns to your datastore's fields, pick an import mode, and the platform processes the rows.
Import Type
The first decision the importer asks for is what kind of import you're doing:
Import All
Every row in your file becomes a new row in the datastore. Fast, but creates duplicates if the data is already there. Suitable for the very first load of a fresh datastore, or for cumulative logs where every imported row is intentionally new.
Import New Only
Checks an existing field (the Unique Key Field) and only adds rows whose unique value isn't already present. Useful for idempotent imports — you can re-run the same import multiple times without creating duplicates. Common for monthly sync files where each month's export overlaps with the previous.
Delete
Finds rows in the datastore whose Unique Key Field matches a value in the import file, and soft-deletes them. Useful for cleanup scripts: "here's a list of inactive customers; soft-delete them all". Combined with audit mode, it's a safe way to bulk-remove without losing the trail.
Unique Key Field
For Import New Only and Delete modes, you pick which column on the datastore is the unique identifier — the one used to match against the file's rows. Common choices:
- Email address for customer or user imports.
- SKU or product code for product imports.
- Reference number for order or transaction imports.
- External system ID for sync imports.
The Unique Key Field should be indexed in the database for performance. The platform usually creates an index automatically when you flag a field as Unique, but check for very large imports.
Column mapping
After uploading the file the importer shows a side-by-side mapper: file columns on the left, datastore fields on the right. For each source column, pick the destination field. Any column you don't map is ignored.
The importer auto-suggests mappings where the file's column header matches a datastore field's row name (or friendly name). Always review the suggestions — column header text can drift between exports, and one wrong mapping can corrupt thousands of rows.
Validation runs at row level
Each row is validated against the datastore's field rules — required fields, type rules, validation rules. If a row fails, the importer reports it and skips that row; the rest of the import continues.
At the end, the importer shows a report listing what succeeded and what didn't, with per-row failure reasons. You can then fix the offending rows in the source file and re-import — Import New Only mode means the already-imported rows won't be duplicated.
Three real-world import scenarios
Scenario 1: Initial customer migration
You're moving from an old system. Export all customers as CSV, upload, map columns to the new datastore's fields. Mode: Import All. Unique Key not needed.
Scenario 2: Monthly product sync
Supplier emails a monthly product list. Some products are new, some are updates to existing ones. Mode: Import New Only. Unique Key: SKU.
Scenario 3: Bulk archive of inactive accounts
Generate a list of accounts that haven't logged in for over a year. Mode: Delete. Unique Key: email. After import, run a verification report to confirm the expected count was deleted.
Tip: Always test imports on a small sample first. Take 10 rows from your source file, run them through the importer, verify the result. Only run the full import once you've confirmed the mappings and validation behaviour are right.