A line-item export created more whole-order tasks than there are orders
Count distinct order identifiers in the source file before assuming the store gained orders. In a line-item export, one order can occupy several rows with order-level fields repeated on the first row and blank on continuation rows, so an importer that treats every row as a whole order manufactures tasks that do not exist. Compare the created tasks against the distinct identifiers, group by the parent order reference, and retire the surplus tasks without losing item detail. Do not cancel or edit real orders while cleaning up the task list.
For: An authorized staff member at a research-only store whose import of an order export created more pick, pack or review tasks than the store actually has orders.
The first question is what one row in the export represents. In Shopify's order export, an order with multiple line items produces multiple rows: the first row carries the order-level fields, and continuation rows carry additional items with some order fields blank. A row is therefore an item line, not an order. Any process that reads rows as orders inflates the order count by exactly the number of extra item lines.
Confirm the actual format of the file that was imported rather than assuming it. Check whether order-level fields repeat on every row, appear only on the first row of each order, or whether the file is one row per order after all. Record the file's origin and settings, because a third-party export tool can produce a different grain from the platform's built-in export, and the repair depends on which file you really have.
Preserve the imported file unchanged. The mapping from rows to tasks can only be audited against the original, and an edited copy destroys the evidence of how the surplus tasks arose.
Count distinct orders, then count tasks
Extract the distinct order identifiers from the source file and count them; that number is how many whole-order tasks the import should have created. Then count the tasks the destination system actually created. If tasks exceed distinct orders, the surplus is an artifact of the import, not a surge of real orders. Record both counts and the identifier list that defines the correct set.
Group the created tasks by their parent order reference. A healthy import shows one whole-order task per identifier, with item detail attached inside it. The failure pattern shows several tasks sharing one identifier, often one per item line, or tasks created from continuation rows whose order-level fields were blank and got filled with empty or carried-over values. Document which pattern you have, because it tells the import's owner exactly which rule misfired.
Check for a second, subtler failure at the same time: blank-field continuation rows imported as tasks with no order reference at all. These orphans can look like corrupt orders and tempt someone to investigate them as customer problems. They are mapping artifacts and should be labeled as such.
Retire surplus tasks without touching real orders
The cleanup target is the destination task list, not the store's orders. For each identifier, keep one whole-order task, merge the item detail from the surplus tasks into it if the import scattered items across tasks, and close the surplus tasks with a recorded reason pointing at the import incident. Have the owner of the destination system confirm the merge preserved every item line before anything is closed.
Do not cancel, refund or edit store orders to make the numbers match. The store's orders are the source of truth and were never wrong; only the imported task list multiplied them. Equally, do not let the cleanup delete an item line that exists in the source file. The reconciliation test is strict: after cleanup, one task per distinct identifier, containing every item line from the source, with no orphans.
If any tasks were already acted on, for example a warehouse picking from duplicated lists, check for physical consequences before closing the incident: the same parcel packed twice, or stock reserved twice. Resolve those with the fulfillment owner using shipment records, not task records.
Fix the mapping rule and name its owner
The durable repair is in the import's mapping: group source rows by the parent order reference, create one destination task per group, and attach item lines as detail. If the import tool cannot group, the export should be produced at order grain instead, or a deduplication step must run before task creation. Record the corrected rule, who implemented it, and the test that proves it: a known multi-item order producing exactly one task.
Assign an owner to the import definition if it recurs. A task list that silently multiplies work costs labor every cycle, and a verification count, distinct identifiers in versus tasks out, catches a recurrence in minutes. Keep the corrected mapping versioned so a later tool change does not quietly reintroduce the row-as-order assumption.
If the import is part of a checkout-to-fulfillment integration whose behavior nobody can fully explain, that is a reasonable topic for a Prism consultation. Describe the platform, the export's grain and the measured task inflation; confirm scope, responsibilities, fees and terms before work. Keep the export file and customer data out of the public inquiry form.
Row-to-task grain reconciliation
Use one sheet per import incident. Count distinct identifiers before counting tasks, group tasks by parent reference, and verify cleanup leaves one task per order with all item detail intact. The store's orders are never edited during cleanup; record counts, references and owners, not customer data.
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.
Row-to-task grain reconciliation. The last column is for temporary notes.
Record or check
What it decides
Your finding
Source file grain: whether rows are item lines or whole orders, and how order-level fields appear on continuation rows.
What it decidesWhether rows can legitimately be read as orders at all; the usual answer is no.
File origin and settings: the export tool and selections that produced the imported file, preserved unchanged.
What it decidesWhich documentation governs the format and where the audit trail lives.
Distinct order identifiers in the source versus tasks created in the destination.
What it decidesThe size of the surplus and the identifier list defining the correct task set.
Task grouping by parent reference: multiple tasks per identifier, or orphan tasks with no reference.
What it decidesWhich mapping rule misfired, which directs the repair.
Item-detail preservation: every source item line present inside the retained task for each identifier.
What it decidesThat merging surplus tasks did not drop any item the warehouse must ship.
Physical consequences: duplicated picks, packs or stock reservations already triggered by the surplus tasks.
What it decidesWhether fulfillment records, not task records, must reconcile real-world effects.
Corrected mapping rule: grouping by parent reference, its owner, version, and the passing one-order-one-task test.
What it decidesA durable fix with a verification count that catches recurrence.
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.
Limits
The multi-row export structure described is Shopify's built-in order export; third-party tools and other platforms need their own format checks.
Cleanup targets the destination task list only; this workflow does not authorize cancelling, refunding or editing store orders.
A corrected import establishes task counts, not product suitability, payment correctness or provider eligibility.
Keep export files and customer data in authorized systems; record identifiers, counts and owners here and in any inquiry.
Shopify: Exporting orders — checked 2026-10-01. In Shopify's order export, an order with multiple line items occupies multiple rows with some order-level fields blank on continuation rows, so one order can span several rows; export scope is selectable and financial and fulfillment statuses are distinct.
Prism solutions — checked 2026-09-21. Consultation scope, responsibilities, fees and terms are discussed before work; an inquiry does not authorize changes to integrations or data.
Get help with store operations
Need help with the order, email or fulfillment step itself?