Import history
Every import is recorded run by run and row by row, so a failed row can be corrected and retried without re-uploading the file.
Import history keeps a record of every import you run: one entry per upload, and inside it one entry per row of the file. It exists so that a file that mostly worked does not have to be uploaded again — you correct the rows that failed, where they failed, and retry just those.
Who can do this
- Role
- Administrators
- Permission
imports:readimports:write
Browsing runs needs imports:read; editing a row and retrying need imports:write plus the run entity’s own write permission. The whole surface is behind the import_history feature — imports themselves still work when it is off, they are just not recorded.
Behind the import_history feature flag. Ask support to enable it for your organisation.
Where to find it
Import History appears in the sidebar once the feature is enabled for your tenant, and it is absent entirely when it is not. Two other routes lead into it: the import dialog on each entity page links through to that entity’s runs, and the result panel of a run you just finished links straight to that run.
What a run records
A run captures what the import was, not just what it did, so a result stays readable months later:
- The upload: file name, detected format, and the mode it ran in.
- The column set: the header the file actually mapped to, kept so the run can be rendered and replayed against the same shape even if you add a custom field afterwards.
- The counts: total, created, updated, failed, skipped, and how many rows carried a warning.
- The timing: when it started, when it finished, and how long it took.
- Who ran it, and when it was last retried.
Run status
| Completed | Rejected | |
|---|---|---|
| What happened | The file was read and its rows processed | The upload bounced before any row ran |
| Typical cause | Nothing — this is the normal outcome | Unreadable file, or a bad header row |
| Has row detail | Yes, one entry per file row | No rows at all |
| Where the reason is | On the individual failed rows | On the run itself, as an error message |
A completed run can still be a total failure. In all-or-nothing mode a single bad row rolls the whole batch back, so the run completes with failures, skips, and nothing written.
Row outcomes
| Status | What it means | Editable and retryable |
|---|---|---|
| Created | A new record was written | No |
| Updated | An existing record was matched and changed | No |
| Failed | The row was rejected, with the reason per field | Yes |
| Skipped | The row was fine but its batch rolled back | Yes |
Warnings sit alongside the status rather than replacing it: a row can be created and warned at the same time. The most common warning is a set of coordinates that Cooriroo derived from the address rather than reading from the file. Created and updated rows link straight to the record they produced.
Fix a row and retry it
Failed and skipped rows keep the payload they were parsed from, which is what makes an in-place fix possible.
- 1
Open the run and filter to what broke
Import History → a run → FailedThe tabs across the row table — All, Created, Updated, Failed, Skipped and Warnings — carry the run’s counts, so you can see at a glance whether it is one stubborn row or a systematic problem.
- 2
Expand the row and correct the cells
The editor is generated from the column set captured at import time, and the field-level errors point at the cells to change. A corrected row is marked as edited so it is obvious it no longer matches the file on disk.
- 3
Retry the rows you chose, or all of them
Import History → a run → Retry selectedRetry selected replays the rows you ticked. Retry all failed/skipped replays every row still in one of those states. Either way the rows go back through the same import engine — the same validation, the same permissions — and the run’s counts are recomputed, so it converges towards all-green.
How long history is kept
When the list is not showing what you expect
A run I know I did is not in the list
Dry runs are hidden by default, and runs of entities you cannot access are filtered out.
Turn on the dry-run toggle in the toolbar to include validation-only runs. If it still does not appear, check that you hold the write permission for that entity — the list hides runs whose detail you would not be allowed to open.
The retry buttons are not there
Retry is offered only on a completed, non-dry run.
A dry run wrote nothing, so there is nothing to converge; a rejected run has no rows to replay. Re-upload the file instead, fixing whatever the run’s error message named.
A retried row fails again with a different message
Retry re-runs the full domain validation, including the checks that need the database.
Shape problems — a malformed date, an unknown enum value — surface on the first pass. Rules that need to look at your data, such as a duplicate licence plate or an exhausted quota, only surface when the row is persisted. A second message is progress, not a regression.