Reliable Shopify warehouse picking is not a product list displayed on a handheld device. It is an execution contract that can answer four questions for every pick: which order state created the task, whether the worker handled the approved variant, whether a scan was applied once, and how the process stops when evidence conflicts. The store, warehouse orchestrator, inventory signal, carrier flow, and customer notice have different responsibilities. One convenient “processed” flag cannot replace those facts.
This guide covers the warehouse pick-and-pack loop: creating a task from an order snapshot, checking locations and variants, recording scan evidence, protecting idempotency, routing exceptions, reviewing decisions, reconciling facts, and recovering from failure. It does not evaluate a fulfillment network, define inventory master data, build supplier visibility, or cover pickup. Validate the store's own order states, variants, locations, staff roles, and warehouse-system boundaries in a development environment before allowing a task to change operational data.
1. Define the completion boundary
1.1 A pick state is not an order state
An order can be created, allocated, picked, scanned, packed, and handed to a downstream carrier at different times. The warehouse task may claim only that an approved warehouse action occurred. A scanned item must not by itself mark an entire order as shipped. Every state needs an origin, time, responsible role, and next action.
1.2 Separate order, task, and scan facts
Order facts include line identifiers, variants, quantities, and customer delivery context. Task facts include assignment, location, batch, and worker claim. Scan facts include the barcode, device, operator, time, and result. Keep these records independent and join them with a non-sensitive association identifier. When the task and order disagree, the task can stop without rewriting the original order.
1.3 Name the cases that cannot be automatic
A variant mismatch, a quantity above the requested amount, an empty or locked location, an order canceled during picking, a changed delivery constraint, or a device that cannot prove its operator should enter an exception queue. An exception is not a skip. It is a business decision with an owner, evidence, a pause state, and a defined recovery path.
| Fact layer | Example | Responsible system | What it may change | What it must not claim |
|---|---|---|---|---|
| Order | Lines, variants, quantity | Shopify store | Order fields under an approved rule | Warehouse completion |
| Task | Task ID, batch, location | Warehouse orchestrator | Assignment and task state | Item shipped |
| Scan | Barcode, device, operator, result | Scan device | Scan event | Customer received item |
| Pack | Parcel, weight, seal check | Packing station | Pack state | Carrier accepted parcel |
| Ship | Carrier receipt and tracking reference | Shipping flow | Shipping confirmation | Every issue is resolved |
2. Create traceable tasks from order snapshots
2.1 Freeze only the fields the task needs
At task creation, store the line identifier, product and variant identifier, requested quantity, location context, approved delivery context, and read time. Do not copy a complete customer profile or unrelated staff note to a picking device. A snapshot is the fact the task saw at that moment; it is not a permanent substitute for the current order state.
2.2 Reassess when the order changes
If a line quantity, variant, cancellation state, or location changes after task creation, the task must not continue with its old list. Mark the snapshot stale, stop the affected line, reread the approved fields, and retain the old snapshot for audit. A correctly scanned line may remain available for review, but it cannot conceal an unconfirmed change.
2.3 Use a stable context identifier
An order number can be mistyped or copied into the wrong screen. A task identifier, line identifier, and snapshot version should be generated and passed together. Printed labels, device caches, and exception items use that association rather than a product name or a customer name. The identifier must not embed personal information.
Compare Shopify API practice for data contracts and failure boundaries for minimum fields and error classification; do not treat an API response as warehouse completion evidence.
| Snapshot field | Why it matters | Stored in | Stale when | Action on stale |
|---|---|---|---|---|
| Order-line ID | Distinguishes lines in one order | Task record | Line is replaced or removed | Stop and reread |
| Variant ID | Prevents same-name mistakes | Task and scan result | Variant changes | Variant review |
| Requested quantity | Defines pick scope | Assignment record | Quantity changes or line canceled | Recalculate |
| Location context | Bounds where work may occur | Allocation record | Location policy changes | Reallocate |
| Snapshot version | Identifies the read basis | Event association | New snapshot exists | Reject old write |
| Read time | Explains the decision | Audit summary | Merchant window expires | Read again |
3. Build an explicit task state machine
3.1 Let states move only through required paths
A useful state set can include pending creation, allocated, ready to pick, picking, exception, review, picked, ready to pack, and canceled. A transition needs an event and an operator or service identity. A refresh or device reconnect must not skip a review. Cancellation and pause are states, not deletion commands.
3.2 Give every state entry and exit evidence
“Picking” requires a valid claim or allocation event. “Picked” requires line quantity, variant, and scan results to agree. “Review” requires a conflict reason and missing evidence. “Canceled” requires a cancellation origin. Without that evidence, the packing or shipping stage must not proceed.
3.3 Make manual review return to a defined state
A reviewer may approve continuation, reassign a location, reduce the allowed scope, reject a scan, or cancel the task. Each decision returns to a named state and retains a reason. Free text alone cannot replace the state machine. If the review dependency is unavailable, keep the task in review rather than changing it to picked.
| State | Entry condition | Required evidence | Permitted next state | Failure action |
|---|---|---|---|---|
| Pending creation | Snapshot passes basic checks | Snapshot version | Allocated or paused | Record validation issue |
| Allocated | Location and role confirmed | Allocation event | Ready to pick | Release allocation |
| Picking | Operator claims task | Claim event | Picked or exception | Retain scanned lines |
| Exception | Scan or order conflict | Conflicting fields | Review or canceled | Lock affected lines |
| Review | Owner receives summary | Decision reason | Picking, picked, or canceled | Remain paused |
| Picked | Every line meets scope | Scan summary | Ready to pack | Recheck lines |
| Ready to pack | Pick evidence complete | Pack task | Sealed or exception | Do not confirm shipment |
4. Validate locations, products, and variants
4.1 Verify identifiers rather than names
One product name can represent different colors, sizes, packages, or market variants. A name helps a worker read the screen, but the final check should use a barcode, variant identifier, or an approved equivalence rule. If an identifier cannot be read, a photo or note may support review; it must not silently pass the pick.
4.2 Separate a suggested location from a pick fact
A suggested bin does not prove that the bin has an available item. Store the suggestion source, the actual scanned location, and any conflict. A count lock, damage hold, or location change can invalidate a suggestion. Stop the line rather than choosing an unapproved alternative.
4.3 Control substitutions and split picks
A substitute needs an equivalence rule, an authorized role, and a clear delivery impact. When one line is split across locations, every child task must point to the same order line and respect the quantity limit. An operator must not choose a substitute or exceed the quantity merely to keep a screen moving.
| Check | Pass condition | Record | On failure | Shortcut to forbid |
|---|---|---|---|---|
| Barcode | Matches approved variant | Scan value and device | Lock line | Name-only approval |
| Variant | Identifier equals snapshot | Snapshot version | Review variant | Similar image as proof |
| Location | Within task scope | Suggested and actual bin | Request reassignment | Unapproved bin swap |
| Quantity | Does not exceed remaining scope | Line counter | Stop scan | Scan first and fix later |
| Substitute | Rule and role are approved | Original, substitute, reason | Keep line in review | Operator choice |
| Split | Child totals stay within scope | Child associations | Pause packing | Unlinked new task |
5. Make scan events replayable evidence
5.1 Record who, when, and what was scanned
Each scan should include the task, order line, snapshot version, device, operator, scan value, result, capture time, and client event identifier. A scan event records an observed action; it does not overwrite order or inventory master data. A reviewer can replay the sequence without relying on the last text displayed on a device.
5.2 Bound offline device storage
If the warehouse network briefly fails, a device may retain validated scan events when the merchant's offline policy permits it. Each event must carry capture time, clock status, and upload state. A cache cannot be kept forever or uploaded without checks after reconnect. The service must recheck the task state, snapshot version, and event identifier before acceptance.
5.3 Retain negative results
Wrong barcode, canceled task, excess quantity, and permission failure are useful evidence. Recording only successful scans hides the health of the rule and the device. A negative result belongs in an exception queue with a clear next action rather than a loop that asks the worker to try the same action again.
| Event field | Purpose | Mutable? | Typical negative result | Audit check |
|---|---|---|---|---|
| Event ID | Idempotent processing | No | Duplicate upload | Applied once |
| Task and line | Object association | No | Line canceled | Old line rejected |
| Snapshot version | Decision basis | No | Version stale | New read required |
| Scan value | Item identification | No | Mismatch | Review created |
| Device and operator | Accountability | Controlled correction only | Role expired | Role valid |
| Capture time | Sequence explanation | No | Clock abnormal | Mark uncertain |
6. Protect quantity with idempotency and ordering
6.1 Let the event identifier decide repetition
Retries, double taps, and device reconnects can submit the same scan more than once. The service should use the event identifier and task context to decide whether it has already processed the event. A repeated request returns the original decision and does not increase the line count. A barcode alone is not enough because the same item may appear in many orders.
6.2 Reject stale ordering
If an old snapshot arrives after a newer snapshot, the handler must reject a write that would overwrite the newer fact using a version or sequence check. The old event can remain in the audit stream, but it cannot move the task backward. An ordering conflict enters review with the difference between the two reads.
6.3 Keep a line boundary inside batch picking
A batch route can share a walking path, but it must not share one success flag with no line-level count. Each line needs its requested quantity, event summary, and exception state. One failed line may remain locked while other verified lines are retained; packing can consume only a complete and consistent order scope.
Use Shopify API performance and query acceptance as a reminder to bound retries and reads; warehouse events still need their own idempotency key and ordering check.
| Situation | Risk | Idempotency key | Ordering rule | Recovery |
|---|---|---|---|---|
| Double scan | Quantity increases twice | Client event ID | One decision | Return original result |
| Network retry | Same event uploads again | Event plus task context | Old request cannot overwrite | Query the result |
| Snapshot update | Old list remains on device | Line and version | Reject stale event | Regenerate line task |
| Batch picking | One failure contaminates all lines | Line event set | Complete by line | Lock incomplete order |
| Device reconnect | Offline events arrive out of order | Client event IDs | Server ordering and review | Hold pending events |
7. Design an exception queue instead of a pile of alerts
7.1 Route by owner and evidence
A barcode issue belongs to the product or warehouse owner, a canceled order to order operations, a role problem to an administrator, and a device clock issue to the technical owner. Each exception includes the affected line, conflicting fields, completed events, and a suggested next action. One generic “system error” queue causes the same issue to bounce between teams.
7.2 Offer pause, retry, and close as distinct actions
Pause preserves the scene while evidence is gathered. Retry is for a known temporary dependency problem. Close means an owner decided to keep the original state, cancel a line, or reassign it. Retry must not become a way to avoid review, and close must state the order or customer effect.
7.3 Resume from a line-level checkpoint
When a batch stops, preserve the last confirmed line checkpoint. Resume only unconfirmed or rejected lines; confirmed events must not be counted again. The checkpoint records the rule version, task version, and owner so a new device does not continue an old context.
| Exception | Evidence summary | Default action | Owner | Close condition |
|---|---|---|---|---|
| Variant mismatch | Scan and snapshot differ | Lock line | Product or warehouse owner | Reread or approve substitute |
| Excess quantity | Scan count exceeds scope | Stop scan | Warehouse owner | Line count reconciled |
| Order canceled | Current state differs | Cancel unexecuted work | Order operations | Cancellation recorded |
| Role failure | Device or operator role issue | Pause task | Administrator | Role reconfirmed |
| Device offline | Upload state and capture time | Hold or pause | Technical owner | Event replay passes |
| Dependency timeout | Request association and result | Query before deciding | Orchestration owner | Result confirmed |
8. Lock the order scope before packing
8.1 Packing consumes complete evidence
The packing station should receive order-line scope, variants, quantities, and a verified scan summary, not just a “picking complete” Boolean. A missing line, unresolved exception, or stale snapshot keeps the pack task in review. This blocks an error before a parcel is sealed.
8.2 Handle partial availability under a rule
If an order may be fulfilled in parts, an approved business rule must define the split and the relationship between each parcel and each order line. Warehouse staff must not create a new promise on their own. Customer notices should use an approved state; “one line found” must not become “everything is ready.”
8.3 Recheck critical differences before sealing
Before sealing, compare the parcel scan summary, order lines, and packing label again. If cancellation, a delivery restriction, or a variant change arrived during picking, stop sealing and return to review. The second check protects against facts diverging during a time gap.
Customer-facing status should use a confirmed summary rather than warehouse events. Account self-service belongs to a separate operating path; use the Shopify customer self-service and human-escalation guide to define external explanations and escalation boundaries.
| Packing gate | Evidence needed | If missing | Safe recovery | State not to send |
|---|---|---|---|---|
| Complete line scope | Decision for every line | Keep in review | Complete or cancel line | Everything ready |
| Variant match | Scan and snapshot agree | Lock parcel | Rescan | Item confirmed |
| Quantity match | Line count meets rule | Do not seal | Reconcile | Quantity correct |
| Task current | Version remains valid | Reread snapshot | Regenerate task | State current |
| Exceptions closed | Owner decision exists | Return to queue | Add evidence | Workflow complete |
9. Protect staff actions and minimum data
9.1 Show each role only its work fields
A picker generally needs the item, variant, quantity, location, and task instruction, not a full customer name, contact method, or order history. A packer needs parcel scope and label data. A reviewer needs conflict fields and an event summary. Design screens and logs by role to reduce mistakes and unnecessary personal-data exposure.
9.2 Put high-impact actions behind an approval
Substitution, location reassignment, releasing a locked task, changing quantity, or reopening a sealed task needs an authorized role. A shortcut on a device must not bypass approval. The decision records the actor, reason, old state, and new decision without copying unrelated customer material.
9.3 Use a minimum customer-context reference
When support or a customer needs an order state, use a safe order and task association, an approved customer-facing state, and an update time. Do not expose bins, staff identities, device identifiers, or raw exception text. If an account surface is involved, its visibility boundary is checked separately.
| Role | Visible fields | Allowed action | Not allowed | Audit focus |
|---|---|---|---|---|
| Picker | Item, variant, quantity, location | Scan and report exception | Change order scope | Event and device |
| Packer | Parcel scope, label, scan summary | Seal check | Approve substitute | Pack evidence |
| Warehouse owner | Task and conflict summary | Reassign, review, pause | Alter privacy request | Decision reason |
| Order operations | Order state and changes | Cancel or approve split | Bypass scan | State origin |
| Technical owner | Dependency and event health | Replay, pause, resume | Change business fact | Version and alert |
10. Reconcile warehouse events with order facts
10.1 Reconcile by line, not only by total
A reconciliation view should list each order line, task snapshot, scanned quantity, exception state, pack state, and downstream confirmation. Matching total pieces is not enough: one variant can be over-picked while another is missing. Each difference returns to the original event and owner.
10.2 Handle duplicate, missing, and unknown events
A duplicate is processed idempotently and retained as evidence. A missing event is recovered from a device cache or task checkpoint. An unknown event must not attach itself to the most similar order. Keep an unknown association isolated until an owner confirms the task and line identifiers.
10.3 Let reconciliation trigger an action
“Consistent” can release the next stage. “Evidence missing” returns to the exception queue. “Unexplainable” pauses the batch and preserves the scene. “Canceled” closes unexecuted work. Reconciliation is an operational gate, not a decorative report.
| Dimension | Consistent when | Example difference | Action | Recovery boundary |
|---|---|---|---|---|
| Order line | Line and variant agree | Similar name, different ID | Lock line | Do not rewrite order |
| Quantity | Scan equals approved scope | Duplicate scan | Idempotency or review | Restore line count |
| Version | Event uses current snapshot | Old offline upload | Reread and pause | Keep old event |
| Parcel | Pack scope equals picked scope | Missing line | Do not seal | Return to packing review |
| Downstream | Receipt is traceable | Unknown response | Query and pause | Do not repeat confirmation |
11. Recover from concrete failures
11.1 Failure case: a similar variant is picked
Two variants have nearly identical names and the device search ranks the wrong one first. The operator approves by text and scans it. If the flow trusts the name, the line moves to picked. The safe recovery is to lock the line, retain the wrong scan as a negative result, block packing, reread the approved variant, and let the owner choose a corrected pick, cancellation, or approved substitute. Deleting the wrong event would create a false clean history.
Test with similar names, similar images, different barcodes, and separate locations. Verify that the wrong scan does not increase the picked quantity, that the parcel is not released, that the reviewer can see the snapshot version and scan value, and that only the approved variant enters the pack scope.
11.2 Failure case: a retry increments quantity twice
A device loses its connection after submitting a scan. The worker sees a timeout and taps again, while the service has already accepted the first event. Without idempotency, the line count increases twice. Use the event identifier to query the original decision; the second request returns “accepted” or “pending confirmation” without another increment. A new submission is allowed only after the service confirms that the original was not accepted.
Test connection reset, delayed response, double tap, refresh, and two devices working on one line. Evidence should show one event, one quantity change, a clear device state, and a traceable log. An uncertain result must not release packing.
11.3 Failure case: an order is canceled after task creation
The order is canceled while a device still holds an old snapshot. On upload, the service checks the current order state and rejects the old task from moving forward. It retains the scans that actually happened, locks unpicked lines, and notifies the order owner. A legitimate scan must not be erased, and an unconfirmed line must not enter packing.
11.4 Failure case: a downstream response is lost
A packing or shipping service accepted a request, but the response disappeared. If orchestration treats the timeout as “not processed” and sends again, it may create a duplicate parcel or confirmation. Query with the original request association first. While the result is unknown, lock the repeat action and show pending confirmation. Only an owner-confirmed, idempotent retry with the current task version can continue.
| Failure signal | Immediate action | Check before resume | Evidence to retain | Do not promise |
|---|---|---|---|---|
| Variant mismatch | Lock line and pack | Snapshot, barcode, substitution rule | Wrong scan event | Original item picked |
| Repeat tap after timeout | Query event result | Key and line count | One event and decision | Retry will succeed |
| Order canceled | Reject stale task | Current state and scans | Before/after snapshot | Parcel will ship |
| Downstream response lost | Lock repeat request | Association and downstream query | Request and result state | Shipment confirmed |
| Device clock abnormal | Hold upload | Event order and capture time | Clock status | Event sequence is exact |
12. Monitor execution quality and dependencies
12.1 Watch state transitions, not only volume
Record snapshot creation, allocation, claim, accepted scan, rejected scan, exception, review decision, packing release, and recovery. Break signals down by task, line, variant, and rule version so total pieces do not hide a failing variant. Monitoring does not require a complete customer profile.
12.2 Use merchant-approved target ranges
Warehouse and technical owners should approve ranges based on their own baseline and capacity. Useful triggers include an exception queue that stays open, a variant repeatedly rejected, offline events waiting too long, duplicate events increasing, or a downstream response that cannot be located. A target range triggers investigation; it is not a promise about processing time or customer outcome. Exceeding it should pause the relevant rule or device path.
12.3 Attach action-ready evidence to alerts
An alert should include batch, rule version, affected line category, last checkpoint, and dependency state. “Pick failed” is not enough. The owner needs to know whether to reread a snapshot, pause a device, replay an event, review a variant, or query a downstream request.
| Signal | Minimum fields | Question | Pause condition | Resume evidence |
|---|---|---|---|---|
| Variant rejects rise | Variant group and rule version | Did item ID or scanner change? | Batch failure unexplained | Sample rescan passes |
| Exception queue stalls | State, age, owner | Is access or ownership blocked? | No accountable owner | Queue sample closed |
| Duplicate events appear | Event ID and line | Is retry uncontrolled? | Count differs | Idempotent replay passes |
| Offline upload delayed | Device and capture time | Network or clock issue? | Order cannot be determined | Events ordered |
| Downstream receipt unknown | Request association | Was it accepted without response? | Repeat risk exists | Query is conclusive |
13. Handle locations, languages, and lifecycle
13.1 A location scopes a task, not a product identity
The same variant may be picked from several locations. Location changes allocation and packing flow; it must not change the product or variant identifier. When work is split, retain each child task's quantity limit and owner, then reconcile by order line.
13.2 Device language does not change warehouse facts
Workers may use translated labels and instructions, but event fields, state values, and identifiers should remain stable. A translation supports reading; it cannot replace a barcode or variant identifier. When label text changes, recheck printed samples and scan behavior.
13.3 Distinguish cancellation, pause, and archive
Cancellation means unexecuted work should not continue. Pause means evidence or a dependency is pending. Archive means the related audit is complete. Do not delete paused tasks to clear a board, and do not reopen a canceled task as a new task without preserving the original association. End-of-life tasks still retain a minimum event summary.
For a broader integration boundary, see Shopify warehouse and picking integration states and exceptions. This guide remains limited to pick-and-pack execution evidence and applies minimum-field, explicit-origin, and verifiable-rollback discipline without copying unrelated customer data to a warehouse device.
| Lifecycle | Meaning | Keep | Allowed action | Prohibited |
|---|---|---|---|---|
| New | Pending task creation | Snapshot and version | Validate and allocate | Pack directly |
| Execution | Picking or exception | Events and owner | Scan, pause, review | Bypass line scope |
| Change | Cancel or reassign | Before/after state and reason | Lock or recalculate | Delete original event |
| Complete | Picked or sealed | Reconciliation and pack evidence | Enter approved downstream flow | Skip on total count |
| Archived | Audit complete | Minimum summary and checkpoint | Query and review | Rewrite history |
14. Plan a pause-and-replay implementation path
14.1 Validate scope with a read-only preview
Generate task previews from order snapshots without changing order or inventory facts. The owner checks variants, quantities, locations, exception gates, and screen fields against the real warehouse procedure. Preview, execution, and reconciliation use the same version identifier so the device list cannot differ from the reviewed list.
14.2 Start small and preserve checkpoints
Each batch states its input boundary, rule version, owner, starting checkpoint, and stop condition. Cover normal, conflicting, and temporarily unavailable-dependency tasks before widening the scope. Pause on scan rejection, event reordering, or a customer-state conflict, then resume from the last passing checkpoint.
14.3 Separate task recovery from external recovery
Task state, unsent scans, controlled allocation, and warehouse labels may be recoverable from a checkpoint. A parcel already sealed, a downstream request already accepted, or a customer notice already sent may require a separate correction process. A state change cannot pretend to erase an external fact. Write these boundaries into the operating procedure and approval record before a task can change data.
14.4 Keep a safe customer-state contract
If a customer-facing page receives an order or parcel state, provide only the confirmed state, its origin, and its update time. Do not expose bins, staff identity, device events, or raw exceptions. If the state is uncertain, show pending confirmation rather than guessing success or failure.
| Stage | Allowed action | Stop condition | Checkpoint | Recovery |
|---|---|---|---|---|
| Preview | Read and generate tasks | Field or version unclear | Task summary | Fix rule and recalculate |
| Small scope | Create controlled tasks and scan events | Variant or quantity conflict | Line events | Lock and review |
| Reconcile | Compare order, task, scan, pack | Difference unexplained | Reconciliation view | Return to exception |
| Expand | Continue within approval | Dependency or queue issue | Batch receipt | Return to checkpoint |
| Close | Archive audit summary | External state unknown | Completion list | Separate correction |
15. Final acceptance checklist
15.1 Tasks and events
Confirm that every task has a snapshot, version, line scope, location, owner, and stop condition. Confirm that scans have unique identifiers, negative results, and replayable order. Confirm that repeated uploads do not increase quantity and stale snapshots cannot overwrite a newer state.
15.2 Exceptions and roles
Confirm that variant, quantity, cancellation, role, device, and downstream-response failures have distinct exception types. Confirm that picker, packer, reviewer, order operations, and technical roles are separated. Confirm that each role sees only the fields required for its work and that substitute, split, and locked-task actions need approval.
15.3 Packing, reconciliation, and recovery
Confirm that packing consumes a complete order scope and verified scan summary. Confirm that reconciliation is line-based. Confirm that a task can pause and resume from a checkpoint. Confirm that sealed parcels, accepted downstream requests, and sent notices have separate external correction boundaries. Confirm that the read-only preview and sample checks finish before an operational write is allowed.
Frequently asked questions
1. Can a successful scan immediately mark an order as shipped?
No. A scan proves that a device observed an item event. Packing, downstream acceptance, and a traceable carrier receipt are different facts. Move through line completion, pack acceptance, and downstream confirmation separately. If any evidence is missing, keep the corresponding stage pending.
2. Can a device keep picking while the network is down?
Only when the merchant's offline policy allows it, the device can retain a minimum event, the service rechecks the task version, and every event has a unique identifier. Reconnection cannot upload events unconditionally. An uncertain order, a canceled task, or a stale snapshot belongs in the exception queue.
3. What should happen to scanned items when the order quantity changes?
Retain the scans that actually occurred, lock the affected line, reread the current snapshot, and calculate the remaining scope. Do not rewrite an old task to the new quantity or delete the old events. An owner decides whether the scanned portion can enter an approved pack path; the rest remains in review or is canceled.
4. How can a team avoid picking a same-name variant without a barcode?
Use a variant identifier, an approved equivalence rule, or additional evidence that a responsible reviewer can inspect. Name and image are reading aids, not proof. Stop the line when the variant cannot be established, and include only the approved variant in the pack scope after correction.
5. Should a timeout trigger another pack or shipping request?
First query the downstream service with the original request association. When the result is unknown, lock the repeat action and show pending confirmation. Retry only after an owner confirms non-acceptance, the idempotency rule remains valid, and the task version is current. An accepted external fact needs a separate correction path.
After the warehouse task passes acceptance, use the Shopify cross-border shipping setup guide to check shipping zones, rates, and carrier configuration; those downstream settings do not replace line-level scan evidence.