Revert a bulk create job and understand its permanent hard delete
Revert a completed bulk create job to permanently hard-delete every SKU it created along with their prices, mappings, inventory, links, tags, properties and 3D models.
A completed bulk create job can be reverted from the jobs list.
Unlike deleting a SKU normally in the catalogue (which is a recoverable soft delete), revert performs a permanent hard delete of every SKU the job created.
Revert permanently hard-deletes every SKU the job created, together with their prices, sales-channel mappings, store and business-unit inventory entries, SKU links (in both directions), tags, additional-property values and 3D-model attachments.
Product groups that the job auto-created are also permanently removed if they end up empty afterwards.
A group is kept if other SKUs were added to it since the job ran.
Only jobs in the completed state can be reverted - a running, failed or already-reverted job returns an error.
Generally prefer fixing the failed rows and re-running a corrected file over revert-and-recreate cycles, since recreated SKUs get new identifiers and lose any references made to the old ones.
When a user runs a bulk SKU upload or bulk edit from the catalogue, the whole batch is applied as a single transaction. If any single row is invalid - an unrecognised column, a SKU the organisation does not own, a missing required value, a SKU id that does not exist - the entire run is cancelled and nothing is applied, including rows that were perfectly valid. This is deliberate: it prevents a half-updated catalogue. What the user sees: the upload is accepted ('Successfully uploaded CSV with N SKUs. Processing in progress.'), but nothing is applied, no failure message follows, and the attempt stays on the In Progress tab of Bulk Edit via CSV; catalogue managers receive an email describing the error (the message usually names the offending field or SKU). What to advise: fix the flagged row and run the whole file again; there is no need to strip out 'already processed' rows because nothing was saved. One important contrast: the separate background 'bulk create job' flow (CSV plus optional assets ZIP uploaded as a job) behaves the opposite way - rows there are processed independently, good rows create SKUs even when other rows fail, and the user gets a per-row success/failure report. So 'one bad row killed my whole file' applies to the bulk upload/edit attempts, not to bulk create jobs.