Facility-aware item routing

Status: Note only — not scheduled, not designed in detail, nothing built. Raised by: David, 2026-07-27, while reviewing the Aurora split-to-site work. Related: Aurora order routing requirements (P1 #6 “Cross-site order movement”), PR #2652 (split-to-site routing).

The gap

PR #2652 makes a split routable: carve an order into line groups and give each group a destination ERP connection. That covers “this PO belongs to two plants.”

It does not cover the much more common case: a whole order that simply belongs to a different facility than the one it landed in. Today an order is bound to one connection, and the only way to move it is to split it into a single split and route that — which is a workaround, not a feature. A non-split order needs to be routable on its own.

The proposed mechanic

Routing should fall out of item matching, not be a separate “move this order” action bolted next to it. The CSR is already searching the catalog to bind a line; that search is exactly where the facility question gets answered.

1. Facilities appear in the item search. Catalog results carry the facility that stocks/produces the item, and the facility is a visible dimension of the result — not hidden metadata.
2. Local facility ranks first. Results from the order’s current facility sort above everything else. The common case (customer ordered something we make here) looks and behaves exactly as it does today; nobody pays a routing tax for a normal order.
3. No local option → surface the routing choice. When the item isn’t available at the local facility, the search shows the facilities that do have it, as the natural next choice rather than a dead end.
4. The chosen result determines where the order goes. Picking a non-local facility’s item is the routing decision. One action binds the line and sets the destination.

The appeal is that the CSR never invokes a routing feature. They do the thing they were already doing — find the item — and routing is the byproduct.

Why this is the right shape

• It matches how Aurora described the work. Robert’s “movement” number (50+ orders/day, 2+ hrs/CSR/day) is CSRs discovering an order isn’t theirs and pushing it elsewhere. The discovery moment is the item lookup.
• It degrades correctly for single-facility customers: one facility means the local bucket always wins and no routing UI ever appears.
• It gives the routing decision a reason that can be shown and audited (“routed to Lunenburg — the only facility carrying GTPE211010”), which is the same signals-with-evidence framing as the POC routing card.

Open questions (deliberately unanswered)

• What defines “local”? The order’s current connection, the CSR’s home facility, or the ship-to? These diverge for a transfer.
• Does routing move the whole order, or only the lines whose items are non-local (which collapses back into the split path)?
• What does the search do when several remote facilities carry the item — rank by inventory, lead time, proximity to ship-to?
• Item identity across facilities: is the same compound one SKU everywhere, or per-facility codes that need the cross-reference layer to equate them?
• Interaction with the existing quote_splits.target_connection_id: is a whole-order route just a destination on the order, or the degenerate one-split case?

Adjacent, smaller: a re-route control on the routing card

Deliberately deferred 2026-07-27 (demo-week freeze), noted so it is not lost.

Today the routing card is read-only. Re-routing an order means leaving it, opening /team, finding the row, and dragging it between plant columns in the Kanban’s “By assignee” lens. That works — it is the POC’s re-route mechanic and it is the better demo, because the same screen also shows load across all eight plants — but it is the wrong ergonomics for a CSR who already has the order open and can see exactly where it should have gone.

The small version: make the card’s destination editable — a site picker that reassigns the work item inline, reusing the same bulk-actions assign path the Kanban drag already calls (org-scoped via isUserInOrganization, so cross-plant already works). Roughly one component plus one handler.

Note this is a different thing from the search-driven routing above. This moves an order whose destination a human has judged wrong. The search-driven version decides the destination in the first place, from item availability. They compose: the picker is the manual override; the search is the proposal.

Not doing now

No implementation, no schema, no flag. This note exists so the idea is not lost between the POC and whatever the real multi-connection build turns out to be — see the eng sizing one-pager for what that build already has to carry.