Skip to content

General

Settings → General holds the store-wide choices that drive how every BOM executionBOM executionEverything Assemblified does when a Shopify order containing a bill-bound variant is created, edited, cancelled or refunded: draw down pre-assembled stock, deduct or restore components, push the changes to Shopify, and cascade dynamic adjustment. It runs in the background, writing one execution log row. Read more → behaves. Five sections, and nothing on the page is a one-way door.

If you are setting the app up for the first time, Initial setup walks these choices in the order the setup guide asks for them. This page is the reference.

  • How the page saves
  • Inventory sync
  • Ignored orders
  • Default location
  • Multi-location sensitive adjustments
  • Beta features

Every control on this page edits a draft. Nothing is written until you press Save on the bar that appears as soon as something changes, and you cannot navigate away with unsaved edits without being asked. Discard puts everything back.

A successful save also marks the setup guide’s review sync preferences step done.

If some settings save and another is refused, the error stays visible and your remaining edits stay in the form. Review the message and press Save again to save only the outstanding changes. Discard restores the values that are currently saved.

Four independent switches.

Disable cancelled orders sync to inventory

Section titled “Disable cancelled orders sync to inventory”

Off (the default), a cancelled order reverses the material inventory changes the original order made in Shopify. On, it does not.

The same choice for refunds. Off, a refund event reverses the material inventory changes; on, it leaves them alone.

Allow negative inventory in Assemblified calculations

Section titled “Allow negative inventory in Assemblified calculations”

Off, Assemblified-managed quantities are clamped at 0. On, they can stay below zero instead.

This applies to virtual materialsVirtual materialA material tracked entirely inside Assemblified — not a Shopify variant. Useful for shop-floor consumables (glue, packaging, labour units) where you need quantity tracking but don't want a Shopify product on your storefront. Read more → , pre-assembledPre-assembled stockStock of finished goods and subassemblies already built and on the shelf, counted per location. For Shopify-linked finished goods, these units are part of the applicable on-hand balance, not extra stock to add to it. A work order draws subassemblies from the shelf first, building fresh only if it runs short; an order consumes a finished good's shelf before its components. Read more → quantities and dynamicDynamic adjustmentA per-bill toggle that recalculates the bill's Shopify-displayed quantity after every order: the bottleneck-resource count plus pre-assembled stock. One of three mutually exclusive toggles — switching it on switches only-sell-pre-assembled and maintain inventory level off. Read more → calculations of buildable quantities. See Allow negative inventoryAllow negative inventoryA store-level setting that decides whether Assemblified-managed quantities — virtual materials, pre-assembled stock, dynamic buildable quantity — can stay below zero, or get clamped at 0. Read more → .

On, when Assemblified takes in an inventory update for a material it knows, it reruns dynamic recalculation for the BOM variants that material feeds. Off, those variants wait for the next event that touches them.

A list of Shopify order tags. An order that already carries one of them when Assemblified first receives it is skipped completely, and stays skipped:

  • no BOM execution and no change to component inventory,
  • no reservation and no tracking between routing and fulfillment,
  • nothing taken when the order is fulfilled, and nothing reversed or restored when it is later cancelled or refunded.

Empty by default, so nothing is ignored.

What it is for. Orders that another app creates for administration, settlement or reporting. They contain real products, but the stock was already handled somewhere else, which is why such orders are often created as already fulfilled without touching inventory (Shopify’s bypass inventory behaviour). Have that app tag those orders when it creates them, for example with Consignatieafrekening, and add the same tag here.

Entering tags. Separate tags with commas. Upper and lower case do not matter, but the whole tag has to match: Consignatie does not match an order tagged Consignatieafrekening. You can list up to 50 tags, each up to 255 characters long. Save stays unavailable while the field holds something that is not a valid list.

When an order counts as ignored. What matters is the order’s tags at the moment Assemblified first receives it, so the tag has to be on the order when it is created.

  • Orders Assemblified has already processed are not affected. Adding the tag to such an order later, or adding a tag to this list later, changes nothing for it, and its cancellations and refunds still restore stock as usual.
  • A change to the list decides only for orders Assemblified first receives after the change.

The decision is permanent for that order. Once an order is ignored, Assemblified remembers it and ignores every later change to it: edits, fulfillments, cancellations and refunds. Removing the tag from the order, or removing it from this list, does not bring the order back. Historical orders replay refuses it too, even with Force re-run on, and shows it as Ignored by order tag.

Where you see it. The order gets one run on the Logs page with the outcome Skipped. Its warning names the tag, for example Ignored: the order carries the tag “Consignatieafrekening”, which is in the Ignored order tags setting. Assemblified does not process this order. Elsewhere in the app: Check missing orders does not report it, it gets no BOM order-status tag, Reservation backfill skips it as Ignored by order tag, and in a multi-store group it is not passed on to the other stores.

The fallback Shopify location Assemblified uses whenever nothing more specific is available — for an order, a refund, a flow, a bill, an assembly BOM or a material action that does not already carry its own location. You can still override it per bill, per assembly BOM, per flow and per material.

Every store has to pick one, even a store with a single location. If your store really does have only one, the picker is disabled and a note says so.

Download Locations exports your Shopify locations as a spreadsheet with each location’s name, its address and its Shopify location ID. The IDs are what you need when you fill in a per-bill or per-flow location override by hand.

See Default locationDefault locationThe Shopify location Assemblified falls back to when an order or fulfillment webhook doesn't carry a more specific location. Inventory adjustments, dynamic recalculations, and per-location records all use this as their anchor. Read more → .

This section decides whether Assemblified uses the location carried by the incoming event, or always falls back to the default location above. See Multi-location modeMulti-location modeA store-level setting that lets Assemblified prefer the location carried by the incoming order or fulfillment event. When off, every adjustment targets the default location regardless of payload. Read more → .

Respect order and fulfillment locations when available

Section titled “Respect order and fulfillment locations when available”

The parent switch. On, Assemblified uses the location on the incoming order or fulfillment event whenever one is there. Off, it falls back to the default location unless a flow, a requirement or a record overrides it.

The tradeoff: in Shopify the definitive fulfillment location is often only known once the fulfillment webhooks arrive. So with this on, BOM execution and the inventory reduction can happen at fulfillment rather than immediately after payment.

The two switches below depend on it. Turn the parent off and both are switched off with it, and each one then says it is available once the parent is on again.

Use location-sensitive dynamic BOM recalculation

Section titled “Use location-sensitive dynamic BOM recalculation”

On, dynamic inventory is recalculated against the relevant location. Off, it uses one shared default-location pool.

Track BOM materials as Shopify-reserved between routing and fulfillment

Section titled “Track BOM materials as Shopify-reserved between routing and fulfillment”

On, materials move from available to reserved at the routed location when an order routes, and are consumed on fulfillment. That closes the over-promise window between order paid and shipped.

Off, routing records a per-fulfillment-order intent and moves no stock; each fulfillment then deducts available stock at its own location, so split orders and partial shipments reduce at the right place.

The tradeoff: with it on, visible storefront stock drops at routing time rather than at fulfillment.

See Order reservations for what this looks like in practice, and Reservation backfill for orders that were already waiting when you turned it on.

Assemblified keeps its own mirrored copy of your inventory. With this on, dynamic calculations and reconciliation read that mirror instead of reading live inventory back from Shopify. Shopify is still updated normally either way.

It is aimed at high-volume stores where reading inventory back from Shopify becomes a bottleneck or turns up temporarily inconsistent numbers.