Reference · built on requestOperator by FibricOrders & fulfillment

Returns Triage

Reads each return request against the order, the product, and your policy, then proposes approve or deny, the refund method, and a label.

Request accessPricing ↗

About

Returns Triage is the job of answering each return request the way your policy says, without a queue. It reads the request from Shopify returns or Loop Returns, the order behind it, the product's eligibility attributes, and the days since delivery. Where the request came through a conversation, it reads that ticket too.

From those facts it proposes a decision: approve or decline with the reason, the refund method the policy allows, and whether a return label goes out. The proposal cites the policy clause it applied. A person confirms or changes it, and the return, the order, and the ticket each keep the outcome.

This is a reference listing. It documents what Fibric would read from Returns Triage and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Return requests with status REQUESTED on Shopify orders, with each ReturnLineItem and the customer's stated reason
  • Returns in Loop Returns in state open or review, their line item outcomes, and the requested outcome: refund, exchange, credit, or a combination
  • The order: items, fulfillment date, payment method, discounts, and earlier returns by the same customer
  • Product attributes that decide eligibility: final sale, exchange-only, hazardous or perishable, and the return window per product family
  • Your return policy as written: window, restocking rules, who pays return shipping, and which items are never returnable
  • The Gorgias or Zendesk ticket when the request arrived by message rather than through the returns portal

Proposed actions

  • Target capability: propose returnApproveRequest, or returnDeclineRequest with a declineReason such as RETURN_PERIOD_ENDED and a note the customer sees
  • Target capability: propose the refund method: original payment through returnRefund, store credit, or an exchange, as the policy allows for that order
  • Target capability: propose a Shippo return label with is_return set, scan-based for USPS, FedEx, or UPS, or no label for a keep-it decision
  • Target capability: propose the Loop process action once the return has an approved outcome
  • Target capability: propose a reply on the ticket stating the decision, the refund path, and what the customer does next

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Approve in-window returns in one step

    A Shopify return requested inside the window on a non-final-sale item gets an approve proposal with a Shippo return label attached; an agent confirms both together.

    With Shopify, Shippo

  • Decline with the clause quoted

    A request past the window gets returnDeclineRequest with RETURN_PERIOD_ENDED and a Gorgias reply naming the policy line and offering an exchange where the policy allows one.

    With Shopify, Gorgias

  • Route low-value items to keep-it

    When the item's value is under the label cost you set, the proposal is a refund or credit with no label, recorded on the Loop return and the Zendesk ticket.

    With Loop Returns, Zendesk

Requirements

  • A store or returns platform that exposes return requests as records: Shopify returns or Loop Returns
  • Product attributes that mark items final sale, exchange-only, or non-returnable, on the product or in a sheet you maintain
  • A written return policy with a window, refund methods, and label rules, so every proposal can cite the clause it applied
  • A label source when you send labels: Shippo, EasyPost, or your own carrier account
  • A named approver for declines and for refunds above a threshold you set
Authentication
A Shopify custom app token with write_returns, a Loop Returns API key, a Shippo API token, and a help desk API key, each stored per deployment.

Limits

  • It applies the policy you wrote; a request the policy does not cover is routed to a person with the gap named
  • A Shopify return can be approved or declined only while its status is REQUESTED; a request changed in the admin is left as it stands
  • Scan-based return labels through Shippo exist only for USPS, FedEx, and UPS, and must use the outbound carrier
  • Refund amounts follow the order's transactions; a restocking fee the store does not record cannot be applied

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Returns Triage ↗

Questions and answers

What does the approver see?
The request, the order, the item's eligibility flags, the policy clause that applies, and a proposed decision: approve or decline, refund to original payment, credit, or exchange, and whether a label goes out. They confirm, change any part, or decline the proposal.
What record is left after a decision?
The return carries its new status and the note; the order carries the refund or exchange; the ticket, when there is one, gets an internal note naming the clause, the approver, and the time. Each entry says how to reverse it.
Does it ever refund or send a label without approval?
No. Every proposal waits for a person, and an approved step is applied once. Requests the policy does not cover, and returns whose status changed in the admin after the proposal was built, are set aside for review.
Ask about Returns Triage

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy