Janson Wang, Founder & CEO, ASG Dropshipping
19 min read
Conceptual illustration (generated image) of a hypothetical order: only the lid line is linked to the complaint. It isn’t a photo of an ASG warehouse or a Shopify or helpdesk screen. Shopify returns automation only helps if the complaint lands on the right order line. A ticket linked to the right order can still point at the wrong item when that order has more than one item.
Here’s the entry-point check I’d use before anyone investigates: which record to trust, and which signals mean a person confirms the match first.
In Shopify returns automation, linking a ticket to an order is not linking it to the item the customer is complaining about. It is the “which order” half of the match, not the “which item” half. Start from where the complaint came in: a self-serve request, a staff-created return, or an email or chat.
Confirm the return belongs to this complaint first. If it’s an actual ReturnLineItem with a readable fulfillment link, follow it to the order line. Otherwise, check the actual order and line items instead of guessing.
Either way, have a person confirm the match whenever you see several open orders, more than one item with no return line to show which, a blank field, or a customer you can’t identify for sure.
The item half also means the quantity and the parcel. A complaint can also cover one unit of three, and that line’s units may have shipped separately.
Why Does Shopify Returns Automation Need Item Checks Where Does the Shopify Return Line Item Point Why Shopify Flow Return Requested Misses Returns Your Team Creates The Linkage Check: Which Record Wins at Each Entry Point Multi-Item Orders: Same SKU, Several Units, Split Parcels A Worked Example: One Cracked Lid, From Email to Verified Link A Ticket Note Template You Can Copy What Should Happen When an Automated Ticket Arrives With Blank Fields Before You Switch It On: Suggested Tests When Is Manual Linking the Better Call Where Does ASG Fit Frequently Asked Questions Final Thoughts Shopify returns automation needs an item-level check because “which order” and “which item” are separate questions. Two merchant threads show each half.
Here’s the thing — the first thread is about the cost of checking orders by hand. One seller scaling a dropshipping store:
“Going through every order manually whenever there’s a complaint is already getting old.”
— u/Terrible_Cookie_8851 on Reddit (r/dropshipping)
The second thread is a different merchant, whose Shopify Flow creates Zendesk tickets on return requests. The ticket and the order link arrived, but not the returned item’s name or SKU.
My reading, not something either seller said: when a ticket answers “which order” but not “which item,” someone ends up back in the order history doing the first seller’s manual check.
Hypothetical order: matching the order and matching the line are two separate checks. Tap to enlarge. HelpdeskMX’s integration guide already covers line items, which store and customer a message belongs to, and approval for some actions. With several orders, it says the agent “should not have to guess which one the message is about.” It doesn’t map a return line to its order line.
Our guide to orders stuck on Processing covers order statuses separately.
That chain is not a complaint match. It is a lead you still check against the complaint before trusting it. Two more things limit it.
On that line item , name and title are non-null, SKU and variant title are nullable, and each line has its own ID. None of that means Flow or your helpdesk shows those fields, and name, SKU or variant (if any) isn’t a unique key.
First limit: the ReturnLineItemType interface also covers “An unverified return line item,” so not every line has that link.
Second limit: what you can read depends on the system.
Layer What you get by default What you can’t assume Layer GraphQL data model What you get by default That path, read through an inline fragment (Shopify staff reply ) What you can’t assume That the same path or syntax works in Flow or your helpdesk, or that the return is the one the customer means Layer Shopify Flow variables What you get by default Only resources from the trigger or earlier steps. Flow’s variable guide : “Flow doesn’t support using indexes to access items in a list.” You loop instead What you can’t assume That a field visible in GraphQL is available in your workflow (not tested here) Layer Helpdesk macros (Gorgias example) What you get by default Gorgias documents “Use orders[0] for the most recent order,” and blank output when data is missingWhat you can’t assume That the most recent order is the one being complained about
That staff reply is a query condition; I haven’t tested how Flow handles it.
In any system, I’d keep the line item’s ID when you can get it. If no ID is available, note the exact line and quantity a person confirmed.
In plain terms: if your ticket can follow that link, it can show the returned item; if it can’t, a person fills the item in. If your helpdesk only shows the order, I’d make line and quantity required fields on return tickets. An agent then can’t close one without saying which item it was about.
Shopify Flow’s Return requested trigger covers one entry point: a customer asking for a return through self-serve returns.
Shopify’s Return requested trigger page says it starts a workflow “when a return is requested by a customer using self-serve returns.”
A merchant whose reps create every return, with no self-serve option, asked:
“how do we detect a return that has been created from the Admin?”
— RSL_IT, Shopify Community, 2025
A Shopify staff member replied that you don’t “request” a return from the admin, you create one, and suggested Return approved, which they hadn’t tested with self-serve returns off.
Shopify’s Return approved page says creating a return in the admin for a fulfilled order “will automatically mark the return as approved.” An approved self-serve return can also fire it; if both workflows create tickets without deduplication, two may result. I haven’t tested it, including with self-serve returns off.
An email complaint doesn’t rule out a return object; one may simply not exist yet. I’d list your store’s real entry points before building anything, including the ones nobody wrote down, like returns agreed on a phone call or created by a returns app.
Entry point Return object? Trigger documented for it What you link from Entry point Customer self-serve return request Return object? Yes Trigger documented for it Return requested (official) What you link from The return’s lines, once the linkage check clears them Entry point Staff create a return in the admin Return object? Yes, once created Trigger documented for it Return approved (official; untested here) What you link from Items staff selected (Shopify’s guide ) Entry point Email, chat or phone complaint with no return yet Return object? No Trigger documented for it None documented here What you link from The customer’s actual order and line items, confirmed by a person
Any entry point without a documented trigger needs a person to make the link. For each one on your list, I’d name who makes that link when nothing fires, so a return agreed on the phone isn’t left waiting for a ticket that won’t arrive.
Every entry point, including email, starts by checking for a return that matches the complaint. Tap to enlarge. The record that wins is the most specific one you can verify for this complaint. If any stop signal in the table applies, it’s the order line a person has confirmed, not one a system picked by default.
Parts of this are standard advice. Shopify’s support-ticket guide has agents ask for the order number when it’s missing. ReturnZap’s walkthrough says to confirm the product and quantity with the customer when an order has several items.
Gorgias matches incoming contacts to Shopify profiles partly by phone number, so the match is only as good as that data.
I’d put those habits into one table of stop points. One wrong-item case:
“Send a refund mailing label just for the one item being returned?”
— KymLeibham, Shopify Community, 2022
The roles are suggestions, not a Shopify rule or any provider’s service.
Signal on the ticket What to check Who confirms (suggested) Record that wins Your note Signal on the ticket Store unclear (multi-store helpdesk) What to check Which storefront the order belongs to Who confirms (suggested) Agent Record that wins Order in the confirmed store Your note Signal on the ticket Contact email or phone doesn’t match the order What to check Customer identity against the order Who confirms (suggested) Agent Record that wins Order verified through your store’s own identity check; if that fails, leave it unlinked Your note Signal on the ticket Customer has more than one open order What to check Which order the complaint names Who confirms (suggested) Agent with customer Record that wins Order number the customer gives, checked against their account Your note Signal on the ticket One order, several items, no return line names the item What to check Which line item and how many units Who confirms (suggested) Agent with customer Record that wins That order line and quantity Your note Signal on the ticket Split or partial fulfillment What to check Which shipments the item left in Who confirms (suggested) Agent or ops Record that wins The relevant fulfillment lines and quantities, checked against fulfillment records and the tracking number Your note Signal on the ticket Name, SKU or variant shows blank What to check Not applicable, not loaded, or item not identified Who confirms (suggested) Agent Record that wins Order line (ID if available) and quantity, looked up by hand Your note Signal on the ticket Item received isn’t the item on the order What to check What was actually packed and shipped Who confirms (suggested) Agent with ops Record that wins The order line, plus a note of the item actually received; unlinked until confirmed Your note Signal on the ticket No return object yet What to check Fulfilled and not refunded? Who confirms (suggested) Authorized agent Record that wins The confirmed order line; link a return line only once one is actually created Your note
If a row still can’t be settled, leave the link as UNKNOWN and say so on the ticket. I wouldn’t pick the likeliest order just to close the loop.
When two rows apply at once, I’d settle them in table order: store, identity, order, item, shipment. A wrong store or customer makes every later answer wrong, so confirming the item first saves nothing.
Write down which record each decision rested on. Our multi-supplier tracking guide shows how to record which items sat in which parcel, and tracing returns to a restock needs that same confirmed line.
Sorting out the fulfillment side of this handoff? Tell us how your orders are packed and shipped today.
Talk to ASG
On a multi-item order, the mix-ups I’d watch for come from records that look identical on a ticket. A product name, even with a SKU, doesn’t say which order line, unit or box the customer means.
The same SKU can sit on two lines of one order; Shopify’s order-editing API , for one, has an option to add a variant that’s already on the order as a new line. The SKU can also sit in two orders from a repeat buyer, and then the order half breaks before the item half does.
Hypothetical SKU and order: price, options and descriptions are clues, not a line key. Tap to enlarge. A line for three mugs with one cracked mug is still one line, but the complaint covers one unit. Shipped separately, those mugs can sit in more than one Shopify fulfillment , each with its own quantities and tracking, and one fulfillment can carry several tracking numbers.
A tracking number the customer quotes is a lead, not the answer. Check it against your fulfillment records, and packing records where you have them, and record the parcel only when that parcel, line and quantity agree; if they conflict, the parcel stays UNKNOWN.
Hypothetical order: a quoted tracking number is checked, not trusted on its own. Tap to enlarge. I’d write these into the linkage check as three plain rules. A line ID counts only once it’s confirmed for this complaint; price, options and the customer’s description are clues for a person, and two lines nobody can tell apart stay unlinked. The quantity is stated every time, as in 1 of 3, and the parcel is recorded only after the fulfillment check.
Here’s how I’d walk one complaint through every step, using a hypothetical order rather than a real store or customer. The order has three lines, a blue mug, a white mug and a lid, shipped in two parcels with the lid on its own. The customer emails from an address that isn’t on the order, saying the lid arrived cracked.
Identity comes first: the agent verifies the customer through the store’s usual check and confirms which order they mean. If either step fails, the ticket stays unlinked and the agent asks for more.
Next comes the item half, before anything is linked. The agent compares the customer’s photo with the order, and the lid line, a quantity of one and parcel 2 count only once the photo, the line and the fulfillment record agree. If the photo shows a lid that isn’t the one on the order, the wrong-item row applies before anything is linked, and the note can record both the wrong item and the crack.
Then the path splits. In path A, the customer also requested a return through the self-serve page that morning, so the agent checks it’s for the same order, lid, quantity and issue, then links the ticket to that return line instead of creating anything new.
In path B, there’s no return yet, and that doesn’t mean one has to be created. An authorized agent decides whether the store will accept a return for this lid, and creates one for that line only if it will and the no-return row’s eligibility check passes. Otherwise the ticket keeps the confirmed order line with no return link.
Hypothetical worked example: no return doesn’t mean one must be created. Tap to enlarge. The step I’d watch most closely is the second ticket. In path A, and in path B once a return exists, a workflow can open its own ticket for that return while the email ticket is still open.
When two tickets look alike, I’d treat them as candidates, not duplicates. A person checks the store, the return ID, the order, the order line, the quantity and the issue described, plus the parcel when the order shipped in more than one. A shared return ID proves nothing on its own, because one return can include several return lines.
Suggested check for your own workflow, not a Shopify feature. Tap to enlarge. Only an authorized agent links or merges, and both tickets keep their history. This is a suggested check for your own workflow, not something Shopify does for you.
I’d keep every return ticket’s note in the same shape, so the next agent can check the link without repeating the lookup. The labels are suggestions to paste into a note, not fields in Shopify or any helpdesk.
Entry point: self-serve / staff-created / email / chat / phone / other (name it)
Store:
Customer verified by: (check used) / not verified
Order:
Order line: (line ID confirmed for this complaint) / (line a person confirmed, and how)
Quantity in complaint: __ of __ ordered
Item actually received:
Parcel (checked against fulfillment records, and packing records if you have them):
Return: none (confirmed) / not applicable (confirmed) / UNKNOWN (not checked or still unconfirmed)
Return status (requested, approved, declined):
Return ID:
Return line: (return line ID or link) / (line and quantity a person confirmed)
Issue described:
Confirmed by: (who and when, for each line)
UNKNOWN (not checked or still unconfirmed), and why:
Confirmed not applicable (N/A):
Possible duplicate of ticket:
Before a link is marked verified, I’d run six checks on the note:
Is the order line named by an ID confirmed for this complaint, or by a person’s confirmation, not by product name alone? Is the quantity stated, even when it’s one? Is the parcel stated if the order shipped in more than one? Can the next agent find the exact return line from the note, not just a yes? Does every blank field say whether it’s UNKNOWN or confirmed N/A? Is a second ticket for the same return marked and linked rather than deleted? A link that fails any check stays unverified, and a person picks it up. The checks cover the linked records, not whether the customer’s issue is resolved.
An excerpt of the template, with UNKNOWN and N/A kept apart; the labels aren’t Shopify fields. Tap to enlarge. When an automated ticket arrives with blank fields, mark the gaps as unknown and send the ticket through the linkage check. I wouldn’t let a blank pass as a clean ticket.
Gorgias, for one, says a macro variable is “replaced with a blank space” when the data isn’t available for that ticket. A separate case comes from Zendesk, where the second thread’s merchant wrote:
“However, this ticket is missing the name or sku of the item returned.”
— u/chefsslaad on Reddit (r/shopify)
Sound familiar? The ticket exists, but the item details your agent needs aren’t on it.
If tickets come through Flow’s Send HTTP request action: “This action is only available to the Shopify Plus, Advanced, or Grow plans.”
It waits up to 30 seconds, then retries; errors set to Retry keep retrying for up to 24 hours. My inference: if the first ticket was created but the reply came late, a retry that nothing deduplicates could open a second.
Failure Signal you can see Conditional response Failure Nothing fired Signal you can see Complaint arrived, no ticket from the workflow Conditional response Check which entry point it came through and whether a trigger is documented for it Failure Fields blank Signal you can see Item name, SKU or variant missing Conditional response Show “UNKNOWN,” then run the linkage check by hand Failure Possible duplicate Signal you can see Two tickets share a return ID Conditional response Treat it as a candidate only. Check whether two workflows fired on one return, then the store, original order, line items, quantities and the issue described before an authorized agent links or merges anything. Keep both records
If the same field comes up blank on ticket after ticket, I’d treat that as a workflow fix to make, not something agents should keep patching by hand.
I’d run a short set of test returns before letting any workflow fill in the item on its own. These are suggested tests, not ones run for this article.
Use fulfilled test orders you control, with self-serve returns on where a test needs them, and keep each one with its ticket as your record.
Test Set it up as Expected on the ticket Passes when Test One line of a multi-item order Set it up as A three-line order; return the lid Expected on the ticket Only the lid line Passes when No mug appears as returned Test One unit of three Set it up as One line with a quantity of three; return one Expected on the ticket A quantity of one Passes when The quantity isn’t copied from the order line Test Split parcel Set it up as A line shipped in two parcels Expected on the ticket The parcel confirmed against fulfillment records, or UNKNOWN sent to a person Passes when No parcel is taken from the customer’s word alone Test Same SKU on two lines Set it up as Two lines with the same SKU, price and options; return one Expected on the ticket No automatic line choice unless a confirmed line ID is present Passes when Neither line is picked by SKU Test Staff-created return Set it up as Create it in the admin Expected on the ticket One ticket from that workflow Passes when Exactly one ticket appears Test Both triggers on Set it up as A self-serve request, then approve it Expected on the ticket One ticket, or a second marked as a candidate Passes when No silent second ticket Test Same return, different issue Set it up as Two tickets on one return, line and quantity, but different issues Expected on the ticket Two candidates kept apart for a person Passes when Nothing merges automatically Test Email complaint, no return Set it up as Email from an address that isn’t on the order Expected on the ticket No automatic link; routed to a person Passes when The ticket stays unlinked until confirmed
If a test fails, I’d fix the workflow before launch rather than train agents to work around it. A failure on the multi-item, same-SKU or split-parcel rows means a person keeps the item half for now.
Suggested tests, not run for this article. Tap to enlarge. Manual linking can be the steadier choice when the customer’s identity and order are clear and volume is low, not because automation gets the link wrong but because someone already reads every ticket anyway. That’s my suggestion, not a measured comparison.
The r/dropshipping seller who started the returns thread called their return rate unremarkable, then asked:
“How do you guys handle this once you’re doing more volume?”
— u/Terrible_Cookie_8851 on Reddit (r/dropshipping)
CoSupport’s returns-automation guide argues for automating more. It splits standard returns from exceptions and wants confidence rules so that “uncertain cases are handed off instead of guessed.”
Even a single-item order can have the wrong customer attached.
The signal I’d watch for the switch is the ticket note itself. Once agents keep confirming the same kind of link the same way, that step is ready to automate; the kinds that keep ending in UNKNOWN aren’t. Our root-cause framework covers where a returns problem starts.
ASG sits on the fulfillment side, not in your helpdesk. Our published scope includes Shopify app integration and ERP automation. This article doesn’t claim a helpdesk or ticket integration, automatic exception alerts, or refund outcomes.
A fulfillment relationship with ASG doesn’t automatically make us your manufacturer or importer of record. It also doesn’t automatically take on legal or tax advice, your platform account, your product and market decisions, or carrier and customs outcomes that weren’t agreed.
One Shopify Community commenter suggested routing by order state “instead of the support team checking each order manually.” My suggestion: keep order and fulfillment records clean on both sides of the handoff, because that matching depends on them.
If you’d like to talk through the fulfillment side of that handoff, contact our team .
How do I get the name or SKU of the returned item into a support ticket? Once the return is confirmed for this complaint, check that Flow or your helpdesk reads an actual ReturnLineItem’s fulfillment link. To test it, compare a test return’s ticket with what was actually returned: the order line and quantity on the ticket must match, and a matching item name alone doesn’t count; if you can’t make that comparison, a person confirms the order line. Keep the line item ID if you can get it; if not, record the exact line and quantity the person confirmed.
Why didn’t my Return requested workflow fire when my team created the return? Shopify documents Return requested for customer self-serve requests only. For admin-created returns, it documents Return approved, untested here.
How can I detect or be notified about a return that staff created in the Shopify admin? Return approved is the documented trigger. Until you’ve seen it fire on your own store, have the agent who creates the return log it against the order line they selected.
Should support handle complaint matching, or should it be automated as volume grows? Use Shopify returns automation where the link can be verified and no stop signal applies. Missing returns, unreadable links and any stop signal in the linkage check go to a person.
How do I return one item from a multi-item order? Confirm the item and quantity with the customer, and an authorized agent decides whether to accept the return. If the store accepts the return, create it only for that fulfilled, unrefunded line. Then link the ticket to that return line, not the whole order.
What if the same SKU appears on two lines of one order? Don’t let the SKU choose the line. Use a line ID only once it’s confirmed for this complaint; otherwise a person confirms the line with the customer, and if the two lines still can’t be told apart, the ticket stays unlinked.
How do I handle repetitive order questions? Let automation fill in the order context it can verify. When a field is blank or several orders match, a person checks first.
Every investigation depends on matching the complaint to the right item. Get that wrong, and everything afterwards analyzes the wrong product.
On our side of the handoff, I’d start any disputed order with one question: which line, from which shipment, and what was actually in the parcel?
Before adding more automation, check whether your linkage process holds up: one entry-point list, one linkage check, a quantity and parcel on every note, a test for each entry point you list, and the habit of writing UNKNOWN when a field is blank. Then let Shopify returns automation handle the cases it can actually verify.
About the author: Janson Wang is the Founder & CEO of ASG Dropshipping, a China-based supply chain and fulfillment partner for growing ecommerce sellers, with warehouses in Shenzhen and Dongguan.
Want to talk through the fulfillment side? Start with how your returns reach the warehouse.
Contact ASG
This article contains no ASG operating figures. The worked example and the diagrams are illustrative, not data from a real store or customer. The hero image is a generated concept illustration of a hypothetical order, not a photo of an ASG facility or a screen from Shopify or a helpdesk. The suggested tests weren’t run for this article. The Shopify, Gorgias and other pages cited here were read on 14 and 15 October 2026, and the Shopify pages behind the new sections were rechecked on 17 October 2026; platform behavior and plan limits can change after that.
