How to use ReturnPath /

Before you begin

Explore the overview and insight screens with example records, or open the private dashboard to see metrics calculated from your saved workflow records.

Create an account in ReturnPath and work in its own private workspace. Accounts and records from another Lumia product are separate. Small commerce and operations teams that need a controlled internal return-authorisation process before connecting a store, warehouse or carrier. A support operator can prepare the case while an owner reviews the policy evidence and records the authorisation or receipt decision.

Follow the workflow below to understand the application. Contact Lumia for a guided walkthrough; account access is private. An exported file reflects the record at the time of export.

Record the order and applicable policy

Enter the customer reference, actual fulfilment time and unique order lines with fulfilled and already-returned quantities. Create a policy with a meaningful version name and return window. Future fulfilment timestamps, duplicate line identifiers and returned quantities exceeding fulfilment are rejected before they become the basis for a case.

Open a case against one order line

Select the order, policy and line, then state the requested quantity and reason. Inspect the evidence: fulfilment time, policy deadline, previously returned units, active authorised quantities and remaining availability. An ineligible request can still appear for review with reasons; its existence does not mean that a return has been approved.

Approve and authorise the reviewed request

The owner approves the current case version and digest. Authorisation checks eligibility again, including competing cases and approval expiry, before issuing a local RMA. An approval lasts no longer than twenty-four hours and cannot extend beyond the policy deadline. Waiting between approval and authorisation can therefore change the permitted action.

Receive the item or release the reservation

After a human checks the arriving goods, record receipt. The server updates the case and order quantity together. If the authorised return will not proceed, cancellation releases its reserved quantity. A received case cannot be cancelled through that path. Exported authorisation paperwork is an internal record, not a prepaid shipping label or refund confirmation.

Operating the product

Start with the public interface preview to explore overview and insights using example records. Open /dashboard for account-scoped metrics calculated from your saved records, or /desk for the underlying workflow.

Use stable order-line identifiers and preserve the policy version associated with a decision. If source data is wrong, resolve it through an explicit operational process; an incorrect fulfilled quantity can undermine otherwise correct availability arithmetic.

When authorisation fails after approval, inspect the current evidence. Another case may have reserved the remaining units, or the approval or policy window may have expired. Do not bypass the rejection by changing identifiers or repeatedly creating new cases.

After an uncertain receipt response, retry the identical command with its original operation key and reload the order. Creating a fresh receipt command before checking the recorded result risks confusing a transport problem with a business action that already completed.

Record receipt only after a responsible person has checked the goods. Authorised, received and refunded are different operating facts; ReturnPath's local receipt should not be used as proof that a refund or inventory disposition occurred elsewhere.

A cancelled authorisation makes its reserved units available again. Review that consequence before cancellation, especially when support and warehouse staff are handling the same order through different channels.