Order Release

Releasing an order commits it to fulfillment. A release is a first-class, tracked record, not an order status, so an order can be re-released, partially released, and audited independently of its own lifecycle.

Every release goes to one of two destinations:

• A fulfillment bridge (BRIDGE_WMS): the order is delivered to an external fulfillment system, such as ShipStation or a connected warehouse/3PL.
• The Dispatch Lane (DISPATCH_LANE): Orderly packs and labels the order itself.

Order Release is gated by the order-release feature flag and needs the orders.release permission. It never buys a label or moves money; a WMS release hands the order to your WMS, and a Dispatch-Lane release places the order in the pick/pack queue where the lane's existing label step remains the only money path.

How the destination is chosen

Order Release does not have its own routing rules. Destination follows the order's dispatch assignment (configured under Dispatchers):

Order → has a dispatcher assigned it to a fulfillment (WMS) bridge? Yes → release to that WMS bridge · No → Dispatch Lane

Dispatchers remain the routing layer. For fulfillment destinations such as ShipStation, matching a dispatcher creates the assignment but does not send the order. Release executes that assignment at the time configured for the organization. Side-channel bridges, such as marketing and support systems, can still receive their dispatcher output immediately.

Releasing orders

From Orders, select one or more orders and choose Release. The dialog re-checks eligibility on the server and shows, per order:

• Eligible: with its destination and who packs/labels it.
• Blocked: with the reasons; blocked orders are skipped.
• Warnings: non-blocking issues you must acknowledge before releasing.

Confirm to release. Fulfillment-bridge releases are queued and confirmed once the destination acknowledges; Dispatch-Lane releases are placed in your lane immediately. In Manual timing mode this happens only after an explicit Release action. In Automatic mode the scheduled release job performs the same checks and delivery when an order enters its configured release window.

Bulk & partial

Bulk release processes each order independently and reports how many were placed, queued, and skipped. Partial release (releasing some line quantities now, backordering the rest) is governed by the Partial policy in settings.

Eligibility

Eligibility is always evaluated on the server immediately before committing - never trusted from the browser. It returns two kinds of signal:

• Blocking codes refuse the release. Common ones: order_cancelled, already_fully_shipped, release_in_progress, on_hold, missing_destination_address, missing_fulfillment_location, outside_ship_date_window, missing_substitution_approval, missing_inventory_allocation, bridge_capability_unsupported.
• Warning codes allow the release once acknowledged: ship_date_past, inventory_partial, contains_substitutions, no_ship_date_policy_allows, bridge_connection_stale, destination_override_used.

Settings

Open Order Settings → Release. The settings are grouped in a section rail:

Routing

Choose the Dispatch Lane fallback location (used when a Dispatch-Lane order has no location of its own) and whether staff may manually override the dispatch-derived destination at release time.

Timing

Controls when an order becomes releasable against its requested ship date:

• Mode: Manual (release only when someone clicks) or Automatic (a daily scheduled job releases in-window orders at your Release at local time).
• Release horizon: how many days ahead of the ship date an order becomes releasable.
• Timezone, Daily cutoff, and Day counting (calendar vs business days, with excluded weekdays and holidays), all date-only math in your timezone.
• No requested ship date / Past ship date: what to do when a date is missing or already in the past (manual review / release / warn / hold).

Ship dates

Where each order's requested ship date comes from:

• Order field: the date the cart/bridge already sent.
• Order tag: a tag like ship-date:2026-08-10 (configurable prefix).
• Order metadata field: a dot-path into the order's metadata.
• Lead time: the order date plus N calendar or business days.
• None: no ship date (falls to the No requested ship date policy).

The timing window above is applied to whichever date this produces.

Inventory check

Inventory is a separate module, stock levels are synced in and out of Orderly via source/destination bridges. At release, a WMS-destined order can be checked against the destination WMS bridge's stock only when that bridge supports inventory:

• Ignore: never check.
• Flag: warn when stock is short, still allow the release.
• Force: block the release when stock is short.

Dispatch-Lane releases never check inventory. A transport error during the check is never treated as "out of stock", Force only blocks on a definitive shortfall.

Ownership

For WMS releases, declare who packs, labels, and may substitute. Dispatch-Lane ownership is fixed (Orderly packs and labels).

Partial & substitutions

• Partial release: require a full release, or allow partial with backorder.
• Max active releases / order: concurrency cap enforced in the database.
• Substitution policy: Not allowed, Require approval, or Allow preapproved mappings.

Fulfillment-bridge delivery lifecycle

A fulfillment-bridge release moves through explicit, server-enforced states:

pending → queued → processing → accepted

with terminal states rejected (WMS business rejection), failed (transport/timeout after bounded retries), and cancelled. Delivery is idempotent and retry-safe: the release's idempotency key guarantees no duplicate WMS order, and a timeout is never treated as a rejection, the release stays recoverable and can be retried. A failed release can be retried from its detail view (needs release.retry_wms).

Substitutions

Orderly never silently swaps a SKU. A proposed substitution blocks the order (missing_substitution_approval) until it is approved (release.approve_substitution), unless your policy allows preapproved mappings. Substitutions the WMS applies on its side are recorded back on the order. When an order is split, each child inherits its parent's approved substitutions, so releasing a child reserves the replacement SKU too (a child's own substitution, if any, wins).

Reservation lifecycle (Orderly-owned inventory)

For orgs where Orderly owns stock, a release reserves the exact released quantities. From there a reservation advances through warehouse stages - reserved → allocated → picked → committed, driven by the Operations Allocate and Mark Picked actions. Allocation and picking don't move stock (it stays reserved); consumption is committed only when the parcel ships. Cancelling an order frees its active reservations at any pre-commit stage; a bare label void does not (the parcel still needs a replacement label).

Troubleshooting

Symptom	Likely cause	Fix
Order won't release, outside_ship_date_window	Ship date is beyond the release horizon	Increase the horizon, or wait until it's in-window (automatic mode releases it for you)
missing_fulfillment_location	No location on the order and no fallback	Assign a location, or set a Dispatch-Lane fallback location
bridge_capability_unsupported	The WMS bridge doesn't support what the policy needs (e.g. partial release)	Adjust the policy or the bridge
Release stuck in processing	WMS hasn't acknowledged, or a timeout left the state unknown	Wait for the ack; retry from the release if it lands in failed
Everything routes to the Dispatch Lane	No dispatcher assigns a release-capable WMS bridge	Configure a dispatcher under Dispatchers