Guide · Results & history

Results and history

Every import — a file you uploaded, a bulk edit, an edit from a product editor, and every dry run — is recorded row by row. History is where you go to find out what happened, and it is the same view whether the run wrote to your store or only previewed.

The run, at a glance

Each card in History is one run: the entity type, the file name, when it started and how long it took, plus a status.

Run status	Means
`Pending`	Queued, not started yet.
`Processing`	At least one batch is still running.
`Finished`	Every batch has run. Some rows may still have failed — see the badges.
`Failed`	Nothing got through at all. A file where some rows failed is Finished, not Failed.

The badges

Badge	Counts rows where
N rows	the file had that many rows for this run.
New	a record was created.
Updated	an existing record was changed.
Deleted	a record was removed.
Skipped	the row said IGNORE, so nothing was looked up or written.
Failed	the row was refused — the reason is in the log.

A badge only appears when its count is above zero, so a clean create-only run shows just N rows and New.

The per-row log

The eye button on a run opens every row it processed:

Column	What it holds
`Row`	The line number in your original file, so you can go straight to it.
`Path / SKU`	The identifier the row was matched by — a SKU, a category path, an email.
`Command`	The command that was applied, after defaulting: a blank cell reads as MERGE.
`Result`	SUCCESS, FAILED or SKIPPED.
`BC ID`	The BigCommerce id that was written. Empty for a failure, a skip, or a dry run that would have created something.
`Message`	Plain English: what changed, or why it was refused.

A dry run's rows read in the conditional — the message begins "Dry run — would: …" and the action reads would create, would update or would delete — so a preview can never be mistaken for a real run when you come back to it later.

Downloading the results

A product spans several rows — a parent row, a row per extra image, a row per variant — so one product's result is written onto every row it came from. That is why the annotation lines up even when a single record covered five lines of your file.

Why a run can sit at Processing for a while

A file becomes several queued jobs, and the run is only marked finished when the last one has completed. Four workers process them in parallel, so a large file finishes far faster than one row at a time — except for categories, which are deliberately run in order so a parent always exists before its children.

If a run is stuck at Processing with nothing progressing, the queue worker is not running — that is a server condition, not a data problem.

Runs you did not start yourself

You will see files in History you never uploaded. Those are the CSVs the app generated for you: a bulk edit, an option restyle, an image reorder, a field change. They are kept exactly so that every write is reconstructable — open the log to see what it did, or download the file to see the rows it ran.