Read and repair the execution logs

The Logs page is the record of everything Assemblified has done: every order it processed, every stock adjustment it made, and every run that failed. It is the first place to look when a number doesn’t match, and it carries the two repair tools for when something was missed.

What the Logs list shows

One row per run. A run is usually an order, but a stock adjustment and a flow run get a row too.

Column	What it tells you
Outcome	how the run ended — see the table below
Type	what kind of run it was: an order, a flow, a manual adjustment, an automatic adjustment
Subject	the order number (or the flow name) the run was about
Bills	how many bills of materials the run processed
Location	the location the run applied to, by name
Date	when the run started

The four outcomes

Outcome	What it means
Succeeded	The run finished and its stock changes were accepted by Shopify.
Pending	The run is still going, or it is waiting for something — most often an order on a multi-location shop that is parked until it ships, so the components come off the location it actually ships from.
Failed	Something went wrong. Either the run itself stopped, or it finished its calculation and the stock changes were rejected. Both read as Failed, because in both cases your stock did not end up where the log says it should.
Skipped	Assemblified decided on purpose that there was nothing to do — a repeat notification for an order it had already handled, a switched-off feature, or an order with no bills on it. A Skipped run is not a problem.

Narrowing the list

The type dropdown above the table switches between All, Orders, Flows, Manual adjustments, Automatic adjustments and Other.
Filter → Outcome takes more than one value at a time: Outcome is one of Failed, Pending is the view to keep open when you are chasing a problem.
Search matches an order number or a flow name, and needs at least three characters — a shorter term would match nearly everything, so it is ignored.
The type, the filter, the search term and the page are all in the page’s address, so a filtered view can be bookmarked or sent to someone else.

What a log’s detail page contains

Select any row to open it. Every run shows some of the following, and nothing it has no data for.

Summary — the outcome, the type, what triggered the run, the date, how long it took, the location, the order it belongs to, and how many times it was retried.
Ordered / Produced / Adjusted — the order’s lines with quantities, plus which bills were processed and which were skipped (and why, for example not built at this location). On an adjustment run this is the before/after quantity per bill, with the component that limited it.
Material changes — one row per component, with its name, SKU, location and the exact calculated change. Two badges above the table say whether the change reached Shopify and, on Enhanced plans, Logistified. If the change was calculated but never applied, the page says so in those words rather than showing you numbers that never happened.
Pre-assembled changes — what came off the shelf as finished stock versus what was assembled from components, and any shortfall.
Errors — every error the run produced, grouped by the stage it came from.

Very large runs are stored in two pieces. If the larger piece cannot be read back, the detail page tells you it is showing a partial record instead of failing — the summary and the outcome are still correct.

Check missing orders

Shopify occasionally fails to notify Assemblified about an order. When that happens the order is paid and shipped but its components were never deducted, and nothing in your stock figures hints at it. Check missing orders finds those orders and lets you put them right.

When to reach for it

Component stock is consistently higher than what you physically have.
You know there was a Shopify outage, or the app was uninstalled and reinstalled.
A specific order’s components look untouched and the Logs list has no row for it.

Step by step

Open Logs and choose Check missing orders in the title bar.
Set how many days to check. The scan never looks back further than a year, and never further back than the day you installed Assemblified — orders older than that could not have been processed by it.
Run the scan. It reads your Shopify orders newest first, in pages, and compares each one with its own records. A long scan can be cancelled, and resumed from where it stopped.
Read the findings, grouped into three lists:
- Missed orders — no record of the order at all.
- Missed fulfillments — the order was recorded and parked waiting to ship, the shipment happened in Shopify, but Assemblified was never told. Multi-location shops only.
- Failed executions — the order was processed and the run failed, with the stage it failed at.
Choose an action for the orders you selected, then reconcile them. A batch is up to ten orders at a time.
Read the results table — one row per order, with what happened to it.

What each action does

Action	What it does
Execute bills	Sends the order back through the normal pipeline: bills are executed and component stock is adjusted, exactly as if the notification had arrived on time. On a multi-location shop an unshipped order is parked until it ships, rather than deducted at your default location.
Mark as ignored	Writes a record saying this order needs nothing, so future scans stop flagging it. Nothing is executed and no stock moves.
Send to Logistified only	Reports the order’s component demand to Logistified without touching Shopify stock. Offered only when the Logistified connection is switched on.

Three things are worth knowing before you press the button:

A failed execution can only be re-run. Execute bills is its only action — marking a failure as ignored is how it quietly disappears. If your selection mixes failures with missed orders and you pick another action, the dialog tells you how many rows it is leaving out.
A re-run is the same run, not a second one. Re-running a failed order continues that execution rather than starting a new one, so components already deducted are not deducted again.
An order Shopify returned incompletely is left out of Execute bills. Orders with very many lines can come back cut short, and executing a part of an order is worse than not executing it. Re-scan with a smaller range to pick those up.

Results read “Queued”

A successful Execute bills answers Queued, not Success — the order has been accepted and its run starts moments later. Refresh the Logs list shortly afterwards and the new row will be there with its real outcome. The other statuses you may see:

Result	Meaning
Queued	accepted; the run happens right after
Success	the record was written (for Mark as ignored and Send to Logistified only)
Superseded	a real run for this order already exists, so nothing was marked — this is a safeguard, not an error
Already reconciled	this scan had already handled this order; nothing was written twice
Nothing to do	there was no component demand to report
Error	read the message on the row, fix that, and run those orders again

Every scan you reconcile from is kept as a record, and Download PDF on the summary step saves the findings if you want them on file.

Duplicate executions

Check duplicates in the Logs title bar opens the Duplicate executions report: orders whose components were reduced by more than the order actually ordered.

It is read-only. It never adjusts stock, never changes a log, and has no repair button of its own. Older versions did, and pushing stock back for units nothing had consumed twice caused more damage than it fixed.
It works from what was actually consumed, not from how many times an order appears in the log. A repeat notification that was correctly skipped is not a duplicate, and the report will not name it.
Each finding says which evidence it rests on: the consumption record for recent orders, or repeated completed runs for orders from before that record existed.
Choose a window — the last 30, 100 or 365 days. Only the most recent orders in the window are examined, and the report says so plainly when it hits that limit rather than implying it checked everything.
Export PDF saves the report.

To actually repair a real over-reduction, use Validate and repair on the material — the report links to it per row. That surface compares the figures and applies the side you choose, with a preview before anything changes.

Where to next

BOM execution end-to-end — what a healthy run does, step by step.
Reconcile inventory — fixing a component’s stock figures directly.
Set up multi-location inventory — why an order can sit as Pending until it ships.
Execution — the execution log in the wider picture.