Only part of a fulfillment batch was accepted

A batch summary is not an order-level result

Record what the batch actually was: its reference, submission time, the orders it contained, the destination system and the summary message it returned. A message like partially completed or a count of failures is a starting point. It does not identify which orders failed, and a success summary on a resubmission does not prove the first attempt failed for those orders.

Shopify's bulk-fulfillment documentation describes failures being reported back for review, which reflects the general shape of bulk operations: the system processes rows and reports per-row outcomes. Read the per-order acknowledgments or error report in the receiving system itself. If that system only gives you a batch-level message, the per-order state is unknown until you inspect each order's record individually.

Resist the two easy mistakes. Treating the whole batch as failed duplicates the accepted work. Treating the whole batch as accepted orphans the failed rows. Both mistakes are made from the summary alone, and both are avoidable with one pass through the order-level records.

Build the order-level result table

For each order in the batch, record the receiving system's acknowledgment: an acceptance reference, a rejection with its reason, or no record at all. Three classes emerge. Accepted rows have a positive acknowledgment. Rejected rows have a failure record and a reason. Unknown rows have neither, and they are the dangerous ones, because the submission may have reached the system without leaving an acknowledgment you can see.

Read rejection reasons at face value and group them. A validation failure on an address field, an unavailable item, an order on hold and a duplicate rejection each need a different fix, and some need no resubmission at all. A duplicate rejection, in particular, may be evidence the order was already accepted earlier — treat it as a lead, not as a failure.

For unknown rows, check the order's state in the receiving system directly: does a fulfillment task, pick record or order entry exist for it, and in what state? The row is classified by what the receiving system shows now, not by what the batch report implies. Mere existence of a record is not enough, because an entry could be a rejected, draft or placeholder record rather than accepted work. Read the record's actual status and the effects it produced, and where the status cannot be determined, the row stays unknown.

Verify what the accepted rows already caused

Acceptance is a system event with physical consequences. For each accepted row, check what the receiving system has already done: a pick task created, stock allocated, a parcel packed or a carrier handoff. That verification matters because the next decision is about not repeating work, and you can only avoid repeating work you have looked for.

Where a third-party fulfillment service owns the work, its records control the relevant status, and your store's copy may lag or miss events. Base the classification on the service's own state, and route any questions through the channel the service actually answers rather than internal notes.

Record the physical state alongside the acceptance, not as a substitute for it. An accepted row with a pick task already completed is doubly confirmed as do-not-resubmit. An accepted row with no visible task yet is still accepted; the work may be queued, and unless the installed integration's deduplication behavior is verified, a resubmission could create a second task ahead of it.

Resubmit only the verified-failed subset

The resubmission file contains exactly the rows verified as failed, each with its failure reason addressed: corrected data, released hold, confirmed stock or whatever the actual rejection cited. A failure reason you cannot address is not a resubmission; it is an exception assigned to a named owner.

Keep the resubmission traceable to the original batch: record which original batch reference each row came from and what changed before the retry. If the receiving system supports idempotency keys or duplicate detection, confirm how the installed integration uses them before relying on them; the safe assumption is that a resubmitted row could create new work.

Unknown rows do not go into the resubmission by default. Each unknown row gets a direct check in the receiving system first. Even a row with no acknowledgment, no order record and no task is not automatically safe to retry, because the original submission could still be queued or in flight. Before retrying apparently absent work, the authorized integration owner reconciles any outstanding processing and confirms the retry and idempotency behavior the installed integration supports; the confirmation is recorded so the decision can be defended later.

Close the batch with owners for the exceptions

The closed batch record accounts for every original row: accepted with its downstream state, failed and resubmitted with the new reference, failed and held as an exception with its owner, or confirmed absent with in-flight processing ruled out and retried. No row should remain classified by the batch summary alone, and no accepted row should appear in any retry file.

If partial acceptance recurs, the pattern is a workflow or integration question: the same rejection reason repeating, or acknowledgments the store never reads, points at whoever maintains the connection. Where the pattern shows up in the storefront's order flow itself, you can describe the platforms and the observed behavior in a Prism consultation request, without order exports or customer records; scope, responsibilities, fees and terms are confirmed before any work.

Batch row classification table

Use one table per partial batch, with one finding per order. Classify from the receiving system's own records, never from the batch summary alone. Accepted rows are never resubmitted; unknown rows are inspected before any retry decision.

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.