A no-charge replacement is missing from the dispatch queue

Confirm the obligation exists before hunting for it

Start with the authorization, not the queue. Locate the decision that promised the replacement: the support case, return or exchange record, or the approved manual order. Record what it covers, which items and quantities were promised, who approved it and when. A queue gap only matters against an obligation that actually exists; a customer's request that was never approved is a different problem from an approved replacement that never shipped.

Identify the record that carries the obligation into fulfillment. Depending on your process that may be a zero-total order created for the replacement, an exchange's replacement items on the original order, or a task sent to a fulfillment service. Write down which form your store used for this case, because the search that follows depends on it. If no such record exists yet, the failure is upstream of the warehouse: the authorization was never handed off.

Read the queue's actual inclusion rule

Shopify's order views are built from filters over attributes such as financial status, fulfillment status, date and sales channel. A dispatch queue saved with a filter like paid and unfulfilled will silently exclude any order whose record carries a different financial status. Whether a given no-charge replacement is excluded depends on the financial status its own record actually holds and on the queue's exact conditions, so verify both rather than assuming the zero total dictated the status. The missing entry may be excluded by design of the view, not missing from the store.

Inspect the saved view or report your warehouse actually uses and write down its exact filter conditions. Then search for the replacement's order reference directly, outside that view. If the order appears in an unfiltered search but not in the queue, you have a filter problem. If it appears nowhere, you have a handoff problem. These two findings lead to different repairs, so record which one you have before changing anything.

Apply the same care to any export used as a work list. Shopify's order export lets you select the scope, and a CSV that opens cleanly still contains only the orders the selected filters and range included. A warehouse working from a morning export can be missing afternoon replacements even when the store's own view is correct.

Check the real fulfillment state, not the financial label

Financial status and fulfillment status are separate attributes in Shopify. A replacement order with nothing to charge can carry a financial label that looks wrong to a warehouse expecting paid, while its fulfillment status is the field that actually says whether work is outstanding. Read the fulfillment state of the replacement's own record: unfulfilled work that was authorized still requires dispatch, whatever the payment label says.

Before creating any new work, check what already exists. A replacement already sitting in a fulfillment service's queue, already partially fulfilled, or already shipped under a reference the support team never saw should not be dispatched again. The goal of this investigation is to route existing authorized work into view, not to generate a duplicate parcel. Record the existing fulfillment reference if there is one, and give it to the warehouse instead of a new order.

If your store's replacements travel as zero-total orders, check what financial status those records actually carry; whatever it is, a mismatch between that status and the queue's filter is a configuration problem, not a defect to fix by charging. Collecting a payment to make reporting tidy creates a refund obligation and misstates the transaction. The repair belongs in the queue definition or the handoff process.

Fix the view or the handoff, with a named owner

For a filter problem, the fix is a queue definition that includes the financial statuses your replacement workflow actually produces, or a dedicated replacement queue keyed to fulfillment state rather than payment state. Record the old filter, the new filter and who approved the change, then verify with a known no-charge order that the view now includes it. This is a reporting configuration decision your team owns; it is not a platform mandate.

For a handoff problem, define where an authorized replacement becomes fulfillment work and who moves it there. Write the rule down, including how zero-charge replacements are flagged so the warehouse does not hold them awaiting payment. If a third-party fulfillment service is involved, confirm how it receives and displays no-charge work rather than assuming it mirrors the store's admin.

If the underlying confusion is that replacements, exchanges and no-charge orders each travel a different undocumented path, that operational tangle is a reasonable topic for a Prism consultation. Describe the workflow and the queue behavior in ordinary language; confirm scope, responsibilities, fees and terms before work. Keep customer details and order exports out of the public inquiry form.

No-charge replacement trace

Use one sheet per missing replacement. Work from the authorization to the queue rule to the real fulfillment state, and record which failure you actually found. Do not create a duplicate dispatch or a charge while completing it; record references, not customer details.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.