Work the backorder queue / allocation pipeline

The Backorder Queue is the tenant-wide, priority-ordered list of every backordered sales-order line — the demand you've sold but can't ship yet. From here you release freed-up stock against waiting orders, link and rebuild the purchase-order coverage that will eventually fill each backorder, re-rank which orders get served first, switch which supplier will resupply, and — once stock is released — submit or void the resulting shipments. This guide walks each of those tasks.

Backorders are a derived state, not a table of their own: a line is backordered whenever it carries a Planned or Awaiting Receipt allocation. Before working the queue, it helps to understand that model — see Allocations and backorders and the Allocations reference.

Before you begin

Requirement	Why it's needed
Orders read/write access	The whole queue and every action on it sit behind the orders scope.
Approved or reserved sales orders with shortages	A backorder only exists once approving a line leaves demand uncovered. See Allocations and backorders.
On-hand stock, and/or open purchase orders	Release needs on-hand available stock; coverage needs open PO lines with unreceived quantity.

One queue, several jobs

Many actions here run as tracked jobs — they queue in the background and report progress in the global job tray, and the table refreshes itself when a matching job finishes. While a job is running, its header button is disabled so you can't stack two conflicting runs. Look for the tray, not a modal progress bar.

Open the queue

Go to Inventory → Backorders (route /inventory/allocation-pipeline; the page is titled Backorders). The page has five sub-tabs:

Sub-tab	What it shows
Allocations	The queue table itself — every backorder, filterable and actionable. This is where you spend most of your time.
Product Analysis	A per-product drilldown for re-ranking priority and reassigning PO coverage one row at a time.
Supplier Analysis	Backorder shortages grouped by supplier.
Breakdown	Active backorders summarized by supplier, product, and month.
Settings	Auto-cover and auto-release behavior for the pipeline.

Three header buttons sit above the tabs: Sync Coverages, Release Allocations, and a Management Tools menu (Reset Priorities, Compact Priority Gaps, Rebalance Coverages). All three are disabled while a matching tracked job is running.

Read the queue table

On the Allocations tab, each row is one backordered allocation. Above the table, a status scope selector narrows the list:

Scope	Rows shown
All	Every allocation, active and released.
Active	Planned and Awaiting Receipt — the true backlog still waiting on stock.
Released (All)	Backorders that have been released to Allocated.
Released (Fulfilled)	Released and already shipped.
Released (Submitted)	Released, with a fulfillment submitted but not yet shipped.
Released (Unfulfilled)	Released to Allocated but with no fulfillment submitted yet.

The bulk-action toolbar changes with the scope, because different actions make sense at different stages:

Scope	Bulk actions offered
Active	Change Supplier, Release Selected
Released (Unfulfilled)	Submit Fulfillments, Unreserve
Released (Submitted)	Void Fulfillments

Most scopes also expose a Selected vs All Filtered toggle so a bulk action can target only the rows you ticked or every row the current filter matches (resolved server-side). The toggle is hidden on the Active tab — releasing is always an explicit-selection action, never "all filtered".

The Priority column here is read-only

The queue table shows each row's Priority but you can't drag or edit it inline. Re-ranking happens on the Product Analysis tab — see Reorder a single backorder.

The Other WH Stock and In Transit columns tell you whether the shortage could be covered from another warehouse or an in-flight transfer instead of waiting on a PO.

Release selected backorders against stock

When stock is on hand for a product, release its waiting backorders to Allocated so they become shippable.

1. Set the status scope to Active.
2. Tick the rows you want to release.
3. Click Release Selected.

SKU.io first runs an availability pre-check: it groups your selection by product and warehouse, sums the available quantity across FIFO layers, and shows a preview splitting your rows into releasable (with a per-row available quantity) and unavailable. Rows with no on-hand availability are listed as unavailable with the reason No available inventory — they stay backordered.

4. Confirm to release. Each releasable row transitions Planned / Awaiting Receipt → Allocated, walking FIFO layers oldest-first and carrying each layer's cost reference.

The result reports how many allocations were released and how many were skipped. Two safeguards shape the outcome:

• Pool headroom clamp. Release is capped at the pool's on-hand available headroom (FIFO on hand minus already-allocated minus holds), so a manual release can never push a product's Allocated total past its on-hand stock and trip an over-allocation health check.
• Partial release splits the row. If only part of the shortage can be covered, that quantity is released and the remainder stays as a backorder.

Releasing surfaces new fulfillable work

A released (Allocated) line gains a shipment plan and becomes fulfillable. From here you can submit the fulfillment (below) or fulfill it from the order — see Fulfill a sales order.

Release allocations across every pool

To release everything SKU.io can — not just a hand-picked selection — use the header button.

1. Click Release Allocations.
2. The button queues a tracked job that walks every product/warehouse pool in priority order and releases each backorder it can against current on-hand stock.

Watch progress in the global job tray; the table refreshes when the job completes. The button is disabled while a Release Backorders job is already running.

This runs automatically too

The same release logic fires on its own whenever stock frees up — a purchase order is received, or a stock hold is released, reduced, or deleted. Manual Release Allocations is for when you want to force a sweep now. Automatic release honors the backorder auto-release setting; the manual sweep overrides it. See Allocations and backorders.

Sync and rebalance PO coverage

Coverage is the link between a backorder and the incoming purchase-order line that will fill it. A covered backorder is Awaiting Receipt; an uncovered one is Planned.

Sync Coverages

Click Sync Coverages (header) to assign open PO-line capacity to Planned backorders. The job matches unreceived PO lines to shortages by resolved ETA (inbound-shipment expected arrival first, then the PO's estimated delivery date) and by priority, moving newly covered backorders to Awaiting Receipt. Only PO lines on a coverable PO — not draft, closed, cancelled, or voided — with unreceived quantity are eligible.

Rebalance Coverages

Open Management Tools → Rebalance Coverages and confirm the dialog. Rebalance tears down every non-tight Awaiting Receipt coverage and rebuilds it from scratch against current resolved ETAs. Use it after PO or inbound ETAs shift, so the earliest-arriving stock is re-matched to the highest-priority backorders. Manually pinned (tight) coverages are preserved — rebalance never touches a link you set by hand. A rebalance can change which PO line covers a given order.

Both actions are tracked jobs and both are disabled while their job runs.

Auto-cover gates both jobs

Sync and rebalance respect the pipeline's backorder auto-cover setting (on the Settings tab). With auto-cover off, both jobs no-op unless forced.

Manage priorities in bulk

Priority decides the order backorders are served when stock arrives — lowest number first, per product. Two bulk tools live under Management Tools.

Reset Priorities

Management Tools → Reset Priorities recomputes every active backorder's priority from a chosen method:

1. Pick the Prioritization Method: By Sales Order Date (oldest first) or By Allocation ID (lowest first).
2. Optionally tick Overwrite tight coverages — when off, manually pinned PO links are left intact and only automatic coverage re-syncs; when on, tight coverage is cleared so re-sync can re-match on the new priority order.
3. Optionally leave Re-sync coverages after reset ticked (the default) to recalculate coverage assignments against the new order.
4. Click Reset Priorities to queue the job.

Compact Priority Gaps

Management Tools → Compact Priority Gaps renumbers each product's priorities to remove gaps left by releases and cancellations. It's purely cosmetic — it preserves the existing order and changes no allocation or coverage.

Both are tracked jobs.

Reorder a single backorder's priority

To hand-rank one order relative to its siblings, use the Product Analysis tab rather than the main table.

1. Open the Product Analysis tab and drill into the product.
2. Under RELEASE ORDER (drag to reorder), use a row's menu: Move up, Move down, Move to top, or Move to bottom (dragging maps to a "move above" of the row you drop onto).

Each move rebalances the sibling priorities for that product in one transaction. Boundaries are no-ops (you can't move the top row up). A "move above" a target on a different product, or a target with no priority, is ignored.

Why not the main queue?

The main queue table's Priority column is deliberately read-only — per-row reordering only exists on Product Analysis, where you see the full release order for one product at a time.

Manually (re)assign or clear PO coverage

To pin a specific incoming PO to one backorder — or to clear its coverage — use Product Analysis.

1. On the Product Analysis drilldown, open a row's Change PO Coverage dialog.
2. The dialog lists open PO lines for that product — non-draft/closed/cancelled/voided, with unreceived quantity, sorted by resolved ETA (earliest first). Each option shows its PO number, unreceived quantity, and ETA.
3. Choose a PO line to pin coverage, or choose No coverage (clear) to remove it.

Pinning sets tight coverage (is_tight_coverage = true) and moves the row to Awaiting Receipt; clearing reverts it to Planned. The product's inventory cache refreshes immediately.

Because a manual assignment is tight, the automatic Sync Coverages and Rebalance Coverages jobs won't touch it — your pin sticks until you change it.

An invalid pin is rejected with a 422 and a clear message when the PO line can't be found, is for a different product, has been fully received, or belongs to a non-coverable (draft/closed/cancelled/voided) purchase order.

Change supplier on active backorders

When the default supplier can't resupply in time, switch which supplier a backorder will be reordered from — in bulk, with a per-row choice.

1. Set the scope to Active and tick the rows.
2. Click Change Supplier.
3. For each selected allocation, the dialog offers only the suppliers actually configured for that product (its supplier products), with the current supplier marked.
4. Pick a supplier per row and apply.

The result reports updated, skipped, and errors. Rows are skipped when they aren't Planned/Awaiting Receipt or when the choice matches the current supplier. Choosing a supplier that isn't configured for the product errors that row (it isn't applied) rather than silently changing it.

Submit, void, and unreserve released backorders

Once backorders are released to Allocated, the released status scopes offer fulfillment actions. All three accept either an explicit selection or All Filtered.

Submit Fulfillments

On Released (Unfulfilled), tick rows and click Submit Fulfillments. This dispatches the fulfillment process for each released allocation's sales order, building the shipments. The result reports how many sales orders were dispatched. See Fulfill a sales order.

Unreserve

On Released (Unfulfilled), Unreserve reverses the release: it reverts each Allocated allocation back to Planned, clears its release source, and assigns it a fresh priority — returning the stock to the pool and the order to the backlog.

Unreserve can flip a global setting

The unreserve dialog includes a disable auto-release option. Ticking it sets the tenant-wide backorder auto-release setting to off as a side effect of this per-selection action — after that, freed stock stops releasing to backorders automatically until you turn it back on. Leave it unticked unless you specifically want to stop all automatic releases.

Void Fulfillments

On Released (Submitted), Void Fulfillments soft-voids the submitted fulfillments for the selected allocations' orders: the shipment rows are retained (not hard-deleted), inventory is reversed, and the order reopens.

"Delete" that doesn't delete

The underlying route is historically named delete-fulfillments, but the action soft-voids — it never destroys the fulfillment record. Provider-cancel failures on individual shipments are collected as per-fulfillment errors and don't abort the rest of the batch. To void a single shipment from the order instead, see Void, restore, or reset a shipment.

Move allocated stock to a backordered line

Sometimes you want to serve a more urgent order first by taking on-hand stock away from a line that's already covered and giving it to one that's still waiting — without changing any physical stock. This conserved swap is surfaced from the Sales Order detail page, not the backorder queue.

1. On a sales order, open the Allocations for an Allocated line and choose to move it.
2. Pick a destination line — the app lists backordered lines in the same product and warehouse pool (the move targets).
3. Enter the quantity (must be greater than zero).

SKU.io then, under a pool lock:

• Releases the destination line's backorders (lowest priority first) to Allocated, carrying the source's FIFO cost reference.
• Shrinks the source allocation by the moved quantity (cancelling it if fully moved).
• Recreates the source line's demand as a fresh Planned backorder, so total committed demand is conserved.

The swap preserves the invariants: total on-hand committed quantity, total demand, and FIFO cost layering are all unchanged. An invalid move returns a 422. Because the source is re-read under the lock, the move aborts if the source is no longer Allocated or its quantity changed since you opened the dialog — refresh and retry.

Export the queue

On the Allocations tab, use the export action to download the current view as XLSX or CSV. Export honors the active status scope, search, and filters, and can target all, the current page, or your selected rows; it exports the visible columns in their on-screen order.

Next steps

• Allocations and backorders — the model behind the queue
• Allocations reference — every allocation, hold, and backorder status and field
• Browse allocations and pin stock to bins
• Place and manage stock holds
• Stock states — on-hand, available, allocated, on-hold, non-sellable
• Fulfill a sales order
• Inventory overview