Historical orders replay

Sometimes an order was placed before you created its BOM — the webhook arrived, but with nothing to consume, Assemblified just logged it as no BOM needed and moved on. Historical orders replay lets you fix that retroactively: select past orders, push them back through the same execution pipeline a live webhook uses, and produce a real execution log + inventory delta.

It also covers a few adjacent cases — re-running an order after fixing a recipe, recovering from a transient failure, or backfilling orders that pre-date the app install.

Where to find it

Settings → Tools → Historical Orders — its own page, reached from the settings navigation. Available to all shops.

A page-wide notice sits at the top and is worth reading once: “Replays only execute the original BOM consumption (create path). Refunds and cancellations on these orders are not replayed.”

How replay works

A replay is not a fake webhook — it’s a real message on the same queue your live order events flow through. The pipeline reuses every step described in the execution model:

You select orders on the Historical Orders page.
Assemblified fetches each order from Shopify (line items, fulfillments, cancellation state).
One job per order is queued and routed through the BOM execution path internally.
The standard pipeline runs. Pre-assembled drawdown, assembly-bill expansion, raw-material decrement, dynamic adjustment cascade — identical to a live order.
An execution log entry is written, tagged as a historical replay rather than a live delivery, so you can tell the two apart when auditing.

Because everything downstream of “job queued” is identical to the live path, anything your live executions do, replays will do too — Logistified sync, metafield writes, dynamic adjustment, the lot. There’s no special path for historical orders.

Picking orders

The page asks “How do you want to choose the orders?” and offers two modes — pick whichever fits the size of your batch. Either lands in the same eligibility table, and you confirm there before anything is queued.

Browse orders

Opens a Shopify-side order browser with search and fulfillment-status filters. Multi-select up to 100 orders per submission and confirm. Eligibility for the selected orders is checked immediately and shown as a badge per row.

Upload list

For larger backfills, paste one order number per line, or upload a CSV with order numbers in the first column, and press Resolve names. Assemblified matches the names against Shopify, shows you which couldn’t be found, and then runs the same eligibility check the picker does.

Eligibility

Before you submit, each selected order is classified into one of five states, from what Assemblified already knows about that order’s execution history:

Badge	Meaning	Default behavior
Eligible	No prior log — order has never been seen by Assemblified. Most common for pre-install orders.	Replays.
Captured (no BOM at time)	A prior log exists but the BOM didn’t exist when the order arrived. This is the primary backfill case.	Replays.
Already executed	A prior run shows the create path ran and a BOM was consumed.	Blocked by default. Force re-run overrides.
In progress	An execution for this order is still running (a live order currently executing, or a stuck replay).	Blocked by default. Force re-run overrides.
Not seen	Nothing at all is known about this order.	Replays.

Above the table, a summary line counts them: “N eligible · N need review · N skipped”, and skipped rows can be hidden or shown.

The same rule decides what the table shows, what the Replay (N) button counts, and what is actually submitted — so the three can never disagree, and a direct API caller cannot bypass it either.

The force re-run override

A Force re-run switch on the left of the eligibility table’s toolbar, beside the Replay button. Its own help text reads “Replay even orders that already had a BOM executed. Risks double-decrementing inventory.” When on:

Already-executed orders replay anyway.
In-progress orders replay anyway.
Cancelled orders replay anyway.
The quantity used is the order’s original line quantity, including any refunded or removed units, rather than what currently remains on the order.

Use it when you know what you’re doing — re-running after a manual fix, recovering a failed batch, replaying a cancelled order whose inventory you want back. Inventory will be decremented again, so check the math first.

Multi-location safeguard

If your shop has Respect order and fulfillment locations when available on (Settings → General → Multi-location sensitive adjustments), replay needs a location to draw inventory from. A live order gets that from its fulfillment events, but a historical order may never have been fulfilled.

Behavior:

Order has at least one fulfillment → replay uses that fulfillment’s location.
Order has no fulfillment → blocked, with the reason “Unfulfilled while multi-location is on”. Force re-run cannot override this — it’s a correctness guard, not a duplicate guard.

Such a row shows the badge Unfulfilled (multi-location enabled) with a link, Reserve it in Reservation backfill. An order that is still open is not something to replay: it should be reserved, so that it is deducted once, at the location it ships from, when it is fulfilled. The link opens Settings → Tools → Reservation backfill on its Open Shopify orders source — see Bring open orders under Assemblified after a stocktake. Replay is for orders that have already shipped: fulfill the order in Shopify first, or turn the setting off, then retry.

A row whose fulfillment state Assemblified has not confirmed yet is also held back: “we have not asked yet” is not a verdict, and force re-run cannot override a question nobody has answered.

What replays don’t do

Replays only run the create path. They never replay:

Cancellations. A cancelled order with force re-run off is skipped, with the reason “Order is cancelled”. With force re-run on, it runs the create path — it does not run the cancel path and does not restore inventory.
Refunds. Refund lines are not replayed. Force re-run uses the full original quantity regardless of refund history; the original execution captured the refunds in its own run.
Edits. Subsequent order edits are not replayed.

If you need the cancel or refund side of an order replayed too, that’s a separate manual flow — historical orders is scoped to the create path only.

Auditing replays

Every replay appears on the Logs page as its own run, tagged as a historical replay. Use the page’s Type switcher, Outcome filter and order-number search to find exactly what was replayed and when, then open a run to see the materials it moved.

Repeated deliveries of the same replay are de-duplicated, so a retry of the same job does not consume twice. A force replay deliberately skips that de-duplication — that is what makes it an override. The order-level “has this been executed before?” question is answered by the eligibility check, not by de-duplication.

Common failure modes

Symptom	Likely cause
Order shows Already executed even though I think it wasn’t	A prior delivery did run successfully. Look the order up on the Logs page. If you want it to run again anyway, switch Force re-run on.
”Unfulfilled while multi-location is on”, can’t override	There is no fulfillment to source a location from. Fulfill in Shopify first, or turn the multi-location setting off.
Eligibility check fails entirely	The table clears and shows the error. Retry; your selection is preserved.
The replay reported an order as skipped with “Could not queue the execution”	Transient failure while queueing. Re-submit just that order.
Force re-run done; inventory looks doubled	Expected. Force re-run intentionally re-decrements. Use a manual inventory adjustment to correct.

Where to next

BOM execution model — the pipeline replays run through.
Refunds & cancellations — why replays only cover the create path.
BOM execution end-to-end guide — a worked walkthrough of one live order, useful context for what a replay re-creates.