Product Updates May
Shipped in May Ongoing connector: expanded workflows Returns don’t always start with the customer. Most return flows assume the customer registers a return, receives a label, and sends ...
Last time we said it was almost here. It’s here.
Orders created in Shopify arrive in Inretrn as soon as they’re fulfilled, so a return can be started against them. From there, every step of the return travels back the other way: created, approved, declined, received, refunded, closed.
Refunds calculate the correct amount, including return shipping fees, and duplicate refunds are blocked before they happen. The integration switches itself on and off when a retailer connects or disconnects their store in the portal settings.
One return, one truth, on both sides.
What this means:
The Brink connector already handled exchanges. It just couldn’t see your stock.
So offering a different size or colour meant offering it blind. The customer picks a replacement, and only afterwards does anyone find out whether it exists. That’s an apology, a refund, and a customer who won’t try the exchange next time.
The connector now checks live inventory as part of the flow. When a return starts, Inretrn identifies the relevant product variants and reads current stock levels in Brink before anything reaches the customer. They only see what’s actually available. And you decide what counts as available, so a single unit left in a warehouse doesn’t have to trigger an offer.
Same integration. It just knows more before it promises anything.
What this means:
Sometimes the right answer is: don’t send it back. The portal had no way to say that.
A return request in the portal ended one of two ways. Either the customer got a shipping label, or they were told the request had gone to customer service. But our rules can already produce a third outcome, one where every line is marked no return because the resolution doesn’t require the item to travel back at all.
That outcome had no screen. The customer was left waiting for a label that was never coming, or contacting support to ask whether they should ship the item anyway.
There’s now a view built for exactly this. It confirms the request is processed, states plainly that nothing needs to be sent back, and explains what happens next. A new rule decision sets no return on the digital return order while the customer is still in the portal, which is what lets the screen appear at the right moment instead of the outcome only surfacing afterwards.
What this means:
In May we said the first updates would land in June. Small on their own, but the start of something bigger. They did. This is the next step.
More of the back office now runs on the new foundation: navigation, search, and the three screens you open most, the ticket list, the sales order list and the returns list. Clearer layout, fresher look, same flows underneath.
Nothing about how your team works day to day has changed. What changed is what it runs on, and how quickly the rest can follow.
What this means:
We’re not finished. The rest of the product moves onto the new foundation the same way it started: in steps you can use right away, rather than one big switch at the end. Expect it to arrive gradually across the coming releases, and expect your day to carry on uninterrupted while it does.
We’ll send you product updates when we release something that actually matters.
Shipped in May Ongoing connector: expanded workflows Returns don’t always start with the customer. Most return flows assume the customer registers a return, receives a label, and sends ...
Learn how Ongoing connector Returns handled in your warehouse shouldn’t create more work upstream. With our Ongoing WMS connector, return data flows automatically between systems. No ma...
Learn how Bulk commercial invoices (Bring API) Customs handling shouldn’t depend on manual work. But in reality, teams often need to gather SKU, value, weight, and product descriptions ...