This article explains how to set up and manage return reasons in the Swap Dashboard, and how to configure the order in which they are presented to customers in the Returns Portal.
This article is for users of Returns V2. For the Returns V1 version, click here.
Setting Up Return Reasons
Open the Returns drop-down menu.
Click Settings.
Open the Return reasons tab.
Click + to add a return reason.
Add a title. This is visible to the customer — for example: Item is too small.
Map the return reason to a Shopify return reason. This appears on the order in Shopify — for example: Size was too small.
Enable any additional settings as required.
Optionally, add sub-reasons by clicking + Add sub reason and naming each one — for example: Too short.
Click Apply.
To edit or delete an existing return reason, use the action buttons on the relevant reason row.
Randomising return reason order
By default, return reasons are presented to customers in the order you have configured. The Randomise Reasons on Display toggle changes this so that the order is shuffled on every new portal session.
This is useful if you want to reduce selection bias in your returns data — presenting reasons in the same position each time can inflate the selection rate of whichever reason appears first.
To enable randomisation:
Open the Return reasons tab in Settings.
Toggle Randomise Reasons on Display to on.
How it works
Each time a customer starts a new return, the list of return reasons is served in a freshly randomised order.
Within a single return session, the order remains consistent — reasons do not re-shuffle if the customer navigates back or refreshes.
Randomisation applies to top-level reasons only. Sub-reasons always appear in their configured order.
The toggle is off by default. Enabling it does not affect any existing return data or configurations.
What randomisation does not affect
The reason selected by the customer is recorded and sent to all webhooks, APIs, and integrations exactly as it would be without randomisation. Display position has no effect on how reasons are logged or processed.
The faulty item flow triggers correctly regardless of where the faulty-tagged reason appears in the randomised list.