Workflows: Use Cases and Limitations

Important: Due to the complexity of Workflows, we recommend publishing and immediately testing a few return scenarios to ensure your desired behaviors are met.

In this article:

Product Workflows 

  • Waive return handling fees in the event that an item arrives damaged
    • Condition: Return Reason; Action: Handling Fees
  • Limit return outcomes for specific products, such as only offering store credit or an exchange
    • Condition: Product Type or SKU; Action: Exclude Outcomes
  • Route certain products directly to your chosen destination, rather than back to your default destination
    • Condition: Product Type, Tag, SKU; Action: Return Outcomes > Select Return Destination
  • Set manual processing events for items that need to be inspected before returns are approved by your team
    • Condition: Any; Action: Return Outcomes > Manual Review
  • Eliminate inline exchanges for single-variant SKUs
    • Condition: SKU; Action: Return Outcomes > select Inline Exchanges
  • Offer free return shipping when testing new product lines or categories
    • Condition: Any; Action: Handling Fees > Waive All Fees
  • Hide products from appearing on the order upon lookup, commonly used for add-on line items like shipping insurance or customization line items
    • Condition: Product Type, Tag, SKU, ID; Action: Hide Products

Order Workflows

  • Control actions based on order discount
    • Condition: Discount Code, Discount Total, or Discount %; Action: Exclude Outcomes
  • Manage customers outcomes based on number of exchanges against a specific order
    • Condition: Return Count; Action: Exclude Outcomes, Handling Fees, or other
  • Extend your return window for the holiday or peak gifting season
    • Condition: Order Date or Order Tag; Action: Return Window
  • Assess a handling fee based on customer's shipping country
    • Condition: Order Country; Action: Handling Fees
  • Make flash sale items final sale
    • Condition: Order Date; Action: Return Outcomes > Reject Items
  • Order tags can be used to identify subscription orders and treat them differently 
    • Condition: Order Tag; Action: depends on intended behavior
  • Configure Shop Now Cart Discount (percentage based) to match the original order's discount
    • Condition: Order Discount Code; Outcome: Shop Now Discount %
    • Example: Customer purchases a $100 item at a 20% discount, resulting in a discount amount of $20. When exchanging via Shop Now, the 20% discount applied on their original purchase would be matched on the new cart value for items exchanged via Shop Now.
    • This Workflow is not the same as Pre-Discount Credit. Pre-Discount Credit offers the original value of discounted items to be used via Shop Now. Whereas, this Workflow passes the original percentage discount to the Shop Now cart.
    • It is not recommended to use both the Pre-Discount Credit & the Shop Now Discount Workflow at the same time. However, if you wish to only offer the Shop Now Discount for certain scenarios, you may combine it with the 'exclude Pre-Discount Credit' action (under Exclude outcomes) to ensure customers are not offered double discounts via the Shop Now experience.
    • This can Workflow is supported on both Shop Now In-App and On-Store experiences.
  • Offer partial credit to a customer to forego the return of a damaged item
    • Condition: Product Return Reason (damaged reasons)
    • Ask a question: Would you like to keep the item and receive X% of your purchase amount?
    • If yes to question > Action 1: Partial Return Credit (X%) and Action 2: Keep Item
    • This relies on the nature of the damage and the subjectivity of the customer, but eliminates returns for cases in which the damage is tolerable for the customer given the option to take partial credit for the item, saving your team time and reducing the cost of returns.

Note: To be used with the 'Ask a question' Workflows template and the Keep Item action.

In addition, you can also control when partial return credits are offered to prevent fraudulent return behaviors:

    • Condition: Customer partial return credit count (less than X)

Note: If a customer accepts the partial return credit and then chooses an exchange item, Loop will charge the price difference between the partial credit item and the new item selected.

Customer Workflows 

  • Offer first time shoppers a tailored customer experience 
    • Condition: Number of Orders; Action: Handling Fees > Waive All Fees, Return Windows
  • Waive fees or extend return windows for your most loyal customers or important internal stakeholders
    • Condition: Customer Tag; Action: Handling Fees > Waive All Fees or Return Windows
  • Keep bad actors or serial returners from receiving Shop Now Bonus Credit
    • Condition: Customer Tag; Action: Bonus Credit > $0

Return Workflows

  • Mitigate fraud by having your warehouse to manually inspect high value returns before the processing event occurs
    • Condition: Return Value (ex: > $300); Action: Return Outcomes > Manual Review
  • Set handling fees based on the number of items in a return
    • Condition: Item Count; Action: Handling Fees > Flat rate
  • Set Bonus Credit to vary based on value of returned merchandise (tier to mirror a % of return value)
    • Condition: Return Value; Action: Bonus Credit

Ask a question Workflows

  • Ask customers a Yes or No question to set an action
    • Condition: Product type; Question: (ex: Have the tags been removed?) Return Outcome: Reject Item
    • Condition: Product type; Question: (ex: Has this item been washed or worn?) Return Outcome > Manual Review

  • Use the Ask a question format to require a photo upload from the customer
    • Condition: Return reason; Photo upload > Manual review

"Count" workflows

All customer-related "count" conditions (for instance: "Number of orders" or "Keep items count") are established before the customer initiates their return and therefore will not include the return actively being created.

For example:

  • "Keep items count" will only include the number of times the customer has kept items before this return.
  • "Number of orders" is completely disconnected from Loop because it analyzes the number of orders the customer has in Shopify. Therefore, this count is whatever that number is at the time the customer looks up their order in the returns portal.
  • Order-related conditions (for example, "Order Return count") will be based on whatever is happening in that return.

Use case: Triggering a workflow off the Order count

Because the customer's order count is already established when the customer begins their return request, the "count" is more straightforward.

If the merchant wants to target a customer on their first order, the customer order count will be "1," meaning the merchant must set the condition to "Customer - Number of orders" is less than "2". (Less than one would indicate that the customer has never ordered before, and less than zero is impossible in this case.)

Image of Customer Number of orders condition set to 'is less than 2'

Use case: Triggering a Keep Item workflow off the Return count

Things that happen during a return, such as Keep Item, will not be included.

If a merchant wants to offer Keep Item to a customer on their first return, the condition must be "Customer - Return count" is less than "1". At the time the customer is creating their first return, their return count is technically "0"; a "less than 2" condition would indicate that the customer will be able to keep their second return, as well.

Image of Customer return count condition set to less than 1 for All time.

Workflows Functionality Limitations

The availability of an extensive list of Conditions and Actions in Loop's Workflows feature allows merchants to support a wide range of return rules and exceptions that fall outside of their typical return policy. Due to this extensive functionality of Workflows, a high level of complexity is introduced when certain Condition/Action combinations are used or when multiple Workflows are enabled and can result in conflicting outcomes, which impacts and potentially hinders or prevents intended functionality.

The below list includes some of the most common attempted Condition and Action combinations that may not produce the desired outcome.

Important: This list is not comprehensive of all potential scenarios, so we strongly recommend testing any Workflows you set up as soon as they are published to ensure functionality.

  • Making products final sale
    • Don't: Action: Exclude Outcomes with ALL return outcomes selected.

    • Do: Action: Reject Item.

    • Why: If the Action is set to Exclude Outcomes with all return outcomes selected, the customer attempting the return request will be unable to proceed further in the returns process without any messaging as to why, creating a confusing customer experience. Instead, using Reject Item will alert the customer that their product is ineligible for return. The Exclude Outcomes Action is meant to exclude one or only a few of the return outcomes, not all.
  • Extending Return Window
    • Don't: Pair the Return Window Action with any Conditions other than the Order Tag Condition.

    • Do: The best Condition to use to extend the return window is the Order Tag.

    • Why: Most of the Conditions available in the Workflows tool are pieces of data that are surfaced after order lookup (i.e., Product Tag, Product Return Reason, etc). The Return Window in your Return Policy settings will be one of the very first rules that gets triggered upon order lookup, preventing the majority of Conditions to be eligible to trigger any Workflow Actions.
  • Pausing the customer from receiving a return shipping label immediately and/or not wanting the customer to ship back their parcel.
    • Don't: Action: Disable Label

    • Do: Action: Manual Review and/or Keep Item

    • Why: The Disable Label Action will prevent a label from generating for the customer, but instead Loop will display your Destination address and instructions for the customer to purchase their own label and mail back their parcel. If this is not your desired outcome, then the Manual Review and/or Keep Item Actions will likely be the better option. The Manual Review Action will pause the return request and flag it for your team's review, which pauses the label generation. Once your team has reviewed and accepted the return request, the customer will then receive their label. The Keep Item Action will bypass label generation altogether and instruct the customer to not ship back their parcel.

Workflows and Listings

There are certain Workflow actions that may be affected by utilizing the Allowlist functionality. The below chart outlines which outcomes are impacted by an Allowlist.

Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.

Related Articles