BOM order-status tags

When an order comes in, Assemblified decides whether to run BOM execution against it. With BOM order tagging enabled, the result of that decision is written back to the order as a Shopify tag. You can then filter, automate, or export based on it.

Turn it on with the Tag orders with their BOM status switch in the BOM order tagging card under Settings → Catalogues → Tags. The same card lists all four tags with their meanings, so you can check them without leaving the page.

The four status tags

Every tagged order receives exactly one of these — the other three are removed if present, so the tag set always reflects the current decision.

Tag	Applied when	What it means
`bom-processed`	At least one matched BOM is active, buildable at the order’s location, and has materials or sub-assemblies to execute.	Assemblified recognized the order as BOM-backed and selected it for execution.
`bom-skipped`	BOMs match the order, but none should run — execution is disabled, the BOM is inactive, or it has no components.	Assemblified recognized BOM candidates, but there was no executable BOM work for this order.
`no-bom-available`	No order-line variant matches an Assemblified BOM — or every matched BOM is turned off at the order’s location by a location rule.	Assemblified checked the order and found no BOM to execute here.
`partially-disabled-at-location`	Some matched BOMs ran, and others are turned off at the order’s location by a location rule.	Part of the order was built from its BOMs; the rest is treated as a plain product at this location.

The four tags are mutually exclusive: when a new status is written, the other three are removed in the same go.

How location rules change the answer

If you use per-location BOM rules, the tag depends on where the order is being fulfilled from, not just on what’s in it.

A BOM that’s disabled at the order’s location isn’t a skipped BOM — at that location it isn’t a BOM at all. So:

Every matched BOM disabled there → no-bom-available, not bom-skipped.
Some disabled, at least one still buildable → partially-disabled-at-location.
None disabled, at least one executable → bom-processed.

That distinction matters if you filter on no-bom-available to find “orders we ship as plain stock”: with location rules in play, the same variant can earn that tag at one location and bom-processed at another.

How to use the tags

A few common patterns:

Filter the orders list in Shopify admin (tag:bom-processed) to see only orders Assemblified handled.
Drive a Shopify Flow — when an order is tagged bom-processed, send it to a specific fulfillment workflow; when no-bom-available, route it as a standard ship-from-stock order.
Audit silent skips — bom-skipped is the tag worth watching. It means a BOM was matched but didn’t run. Common causes: BOM disabled, BOM has no components, or execution is globally disabled in Settings.
Watch for partial builds — partially-disabled-at-location is the one to route to a human. Some of the order was built from its bills and some of it wasn’t, which is rarely what a downstream automation assumes.

Enabling and disabling

That one switch enables or disables the feature globally, and takes effect immediately. Disabling stops new orders from being tagged but does not remove tags from previously tagged orders — they stay until you clear them manually in Shopify.

Re-enabling resumes tagging from the next order onward.

When tags get written

Order tagging fires as part of BOM execution evaluation — the same path that decides whether to consume components, expand sub-assemblies, and write execution log entries. It runs on the standard orders/updated Shopify webhook delivery.

If the Shopify webhook never arrives (delivery failure, app uninstalled between events), no tag is written. Re-delivering the webhook from the Shopify admin will retroactively tag the order.

What’s not tagged

Draft orders. Tagging fires on the live order event, not on drafts.
Orders processed before the toggle was enabled. There’s no back-fill — the historical orders replay tool is for BOM execution, not for tag back-fill.
Orders that reached this shop from another store in a multi-store group. The tag is written against an order in this Shopify store, and a partner store’s order doesn’t exist here.
Orders without a Shopify session in scope (rare — usually means the app session was rotated mid-flight).