Route a returns request to a tagged customer record
Each returns request tags the matching Shopify customer returns-open and logs the order number and complaint in their note.
New submission on your returns and support form
Add tags to the customer in Shopify and attach the request as a note
One-directional. A submission triggers the action — nothing is written back into your form.
A returns request is a support case pretending to be a form. It needs to end up next to the buyer's order history, not in a mailbox. This flow finds the matching Shopify customer, tags them, and writes the order number and the complaint into their note.
Online shops without a dedicated returns app use it to build a queue out of a saved customer view. The tag holds the state: it goes on when the request arrives, and a person takes it off when the case is closed.
Setting it up
- 1
Publish the returns form and make Email Address and Order Number required. Without the email there is no Shopify customer to tag, and without the order number the tag says nothing useful.
- 2
Agree the tag vocabulary before building anything: returns-open, plus one tag per Reason for Return answer. Ad-hoc tags are why returns queues stop being searchable after a month.
- 3
In Zapier, set formformform as the trigger app, choose New Submission, connect the account, pick the returns form and load a real request as test data.
- 4
Add a Shopify Find Customer step searching on Email Address, so the request attaches to the record that already carries the buyer's order history.
- 5
Add the Shopify Add Tags to Customer action, point it at the customer the search returned, and set the tags to returns-open plus the Reason for Return answer.
- 6
Add a second Shopify step that writes the note: Order Number and Product Name first, then Description of Issue. The action replaces the note rather than appending, so map the existing note from the search step ahead of the new text.
- 7
In Shopify, save a customer view filtered on returns-open. That view is the queue your staff work from, and it is only accurate if people clear the tag.
- 8
Test with a real order, check both the tag and the note in the admin, then turn the Zap on.
What maps where
Using the Product Return Request Form as the starting point. These are its real fields — swap in your own and the mapping works the same way.
| Form field | Shopify |
|---|---|
| Email Address | Search key for Find Customer, then the customer tagged |
| Order Number | First line of the customer note |
| Product Name | Customer note, beside the order number |
| Reason for Return | Second tag, such as return-damaged |
| Preferred Resolution | Third tag, refund-requested or exchange-requested |
| Description of Issue | Body of the customer note support reads first |
Variations worth knowing
Branch on Preferred Resolution with Zapier Paths and write refund-requested on one side, exchange-requested on the other. Two saved customer views then cover two different jobs: one person works through refunds in the admin, another checks whether replacement stock is on the shelf.
Guest orders sometimes have no customer record at all, so the search comes back empty and the Zap stops. Add a path for the no-match case that runs Create Customer with the name and email from the form plus the returns-open tag, so the request still lands somewhere a colleague will find it.
If something isn't arriving
The email on the form has to match the one on the order exactly, and people order on a work address then complain from a personal one. Ask for the email as it appears on their confirmation, and add the fallback path that creates a tagged customer when the search misses.
Shopify's update action replaces the note instead of adding to it, so a second request wipes the first. Map the existing note from the Find Customer step into the front of the new value, or keep only the order number in the note and read the detail in your responses list.
Frequently asked questions
Does the returns-open tag clear itself when the case is done?
No. Everything here runs from form to Shopify and never the other way, so nothing removes the tag on its own. A person clears it in the admin when the case closes, which is precisely what keeps the saved view an honest queue.
Should this create a return in Shopify rather than a tag?
Shopify returns are raised against an order and need the specific line items chosen. A tag and a note match what a form actually knows: who the buyer is, which order they mean, and what they say went wrong with it.
Does this work alongside a returns app?
Most returns apps read the Shopify customer and order, so a tag sits beside them rather than fighting them. Use the form for the first step, capturing and queueing the request before anyone decides whether it becomes a formal return.
Related automations
- Add a wholesale lead to your Shopify customers
Each wholesale application creates a Shopify customer with the business name, buyer contact and address already filled in.
- Capture pre-orders before a product drop
Each pre-order becomes a draft order tagged with the drop name, so demand is countable in Shopify before the run is committed.
- Draft an order from a custom quote request
A quote request lands in Shopify as a draft order with the customer attached and the brief in the note, waiting to be priced.
- Grow your marketing list with tagged customers
Each signup becomes a Shopify customer tagged newsletter, so the segment your campaigns send to stays current without an import.
- Tag VIP and loyalty signups
Every membership signup creates a Shopify customer carrying the VIP tag your early-access segments and discounts are built on.
- Add a made-to-order build to the catalogue as a draft
Every build request creates a draft WooCommerce product carrying the item name, its part number as SKU and the full specification.
Build the form first
The automation needs somewhere to fire from. Publish a form, connect it once, and every submission from then on runs this flow.
Start free