Quick answer
Supervisors should triage blockers by first confirming the workflow owner: picking method, route setup, exception category, scan/setup issue, order status, or product/inventory data. Pause before repeating route generation, changing exception state, or releasing holds when the effect is unclear.
Common use cases
Warehouse supervisor: Decide whether an associate blocker belongs to picking, route, batch, scan, product, inventory, or support.
Operations lead: Review route creation failures and exception queues before escalating.
Support: Receive a complete blocker packet instead of raw screenshots without context.
When to use this
Route generation fails or route work does not appear.
An order appears in an exception, back order, failed-sync, delivery, product-sync, or receiving-validation queue.
Associates disagree on which picking method to use.
A scan, container, or workflow action is rejected.
Before you start
Confirm warehouse, merchant, order set, and workflow source before changing operational state.
Avoid retrying route generation repeatedly when the app returns unclear errors.
Do not instruct associates to scan the visible SKU unless Product confirms it is the accepted scan code for that workflow.
Steps
Identify the blocker type: route, picking method, scan/container, order exception, product sync, receiving, or order status.
Confirm the source surface: Fulfill Orders, Batch Orders, Order Dashboard, Exceptions, Back Orders, Delivery Issues, Products, or Receiving.
Check existing filters, warehouse, merchant, saved view, and order count.
Collect exact setup values for route or batch issues.
Collect exact scan input and screen for scan/container issues.
Use the linked article for the specific blocker before changing state.
Escalate with the evidence checklist when the action semantics or blocker cause are unclear.
Screenshots
Screenshot: Use Fulfill Orders to confirm warehouse, saved view, and picking method before starting route, batch, or regular picking work.
Screenshot: Use Exceptions to confirm whether blocked orders are already categorized before changing operational state.
What good looks like
The supervisor can route the issue to the right owner, avoid unsafe operational changes, and give support enough evidence to investigate quickly.
Common issues and next actions
If this happens | What to do next |
Route creation fails. | Collect warehouse, merchant, order count, product limit, bin count, route method, timestamp, and screenshot. |
The team chose the wrong picking method. | Use the picking method guide and choose the least specialized workflow that fits the job. |
An exception action is unclear. | Do not click Resolve, Unresolve, BackOrder, Validate, or Discard until the effect is confirmed. |
Contact us when
Contact support when a blocker affects live fulfillment, route generation returns unclear errors, exception actions are ambiguous, or a scan/container issue cannot be explained from the current workflow.
Send us this information
Workspace or merchant and warehouse.
Blocker type and source surface.
Order, route, batch, saved view, activity, SKU, tote, container, or receiving order.
Setup values or filters used.
Exact error and timestamp.
Recent actions before the blocker.
Screenshot with private customer data masked.