Returns are a different job from packing. Different staff often handle them; the workflow has different stakes (you’re moving money, not just goods); and the actions need different authorisation.
The frontend returns dashboard is a separate page from the packing dashboard, with its own role list and its own per-action permissions. Your returns team logs in, lands on the returns page, sees what’s inbound, and works through it — without needing wp-admin access and without you having to think about what else they can or can’t see while they’re in there.
Setting it up
Like the packing dashboard, you build any page on your site (Bricks, Gutenberg, your page builder of choice) and drop in either:
- The
[tracksies_returns_dashboard]shortcode, or - The Packsie Staff Dashboard Bricks element with its Default tab set to Returns
Save, share the URL with your returns team, done.
What the page shows
A list of pending returns, each with the customer’s stated reason, the items being returned, and the resolution they requested (refund, replacement, or both, depending on what your per-item refund policy allows for those products).
Click into a return and you see:
- Item-by-item inspection. Record the condition of each returned item, mark it as accepted or rejected, add notes.
- Resolution actions. For replacement items, dispatch the replacement (with a variation picker for variable products and a stock check). For refund items, queue the refund.
- Mixed-resolution flow. A single return can refund some items and replace others. The dashboard handles both action groups side by side and only marks the return closed when every item is resolved.
- Customer context. Each card shows tags, lifetime value, and recent order history so staff can flag VIPs, repeat returners, or anything that should change how this return is handled.
Refund authorisation as a separate permission
The single most consequential action in the returns workflow is the moment the refund actually goes through. That click moves money out of your account, so it earns its own permission switch.
Packsie splits “process the return” from “authorise the refund” so you can give them to different people:
- A returns inspector role (Packer, or a custom role you create) is allowed to receive the return, record condition, and recommend a refund.
- A refund authoriser role (typically Shop Manager and Administrator, or a custom role you tick on) is the only one who can actually release the refund.
When a returns inspector clicks Refund on a return, the action queues for an authorised user to approve. The authorising user gets the queued request in their dashboard and clicks Approve when they’ve checked the work. The actual refund (Stripe / Square / WooCommerce manual) only fires at that point.
You can also collapse the two roles back into one for shops where the same person does both jobs. Tick the refund-authoriser permission for the inspector role and the queued step is skipped.
Built-in protections
The returns dashboard inherits the same guard rails as the packing dashboard:
- Search engines are blocked. A
noindex, nofollowrobots meta tag is added automatically to any page where the dashboard renders. Google won’t list it. - Logged-out visitors are redirected to the login page (with a return URL back to the dashboard so they land there after signing in). Logged-in users without the right role see an Access Denied panel pointing back to the homepage. The redirect target is configurable in settings.
- Role membership is checked on every render. Packsie reads the per-role tab-permission matrix in Packsie Settings → Tab Permissions. Only roles with the Returns column ticked can access this surface — Administrator and Shop Manager are ticked by default, so most shops only configure custom roles like a Returns Lead.
- Capability is also checked. The same
manage_packingcapability gates rendering, with the additional refund-authorisation check on the action that releases money. - Every action is nonce-verified and re-checked. Inspection actions, refund queues, and refund approvals all re-validate the user on submission. Stale tabs and shared sessions can’t fire actions inappropriately.
If a returns staffer accidentally shares the URL or someone bookmarks it on a browser they later use for personal browsing, the page produces nothing useful for anyone but an authorised user.
Pairing with the packing dashboard
Most shops use both. The two dashboards live on separate pages so each role goes straight to their work without the other team’s queue cluttering the screen. Same shortcode pattern, same role-and-permission grid, same protections, separate surfaces.
Why we built it this way
Returns are higher-stakes than packing because money’s involved. You should be able to grow your team — let someone receive returns, inspect them, recommend resolutions — without giving everyone the keys to the float. The frontend dashboard plus the refund-authorisation split lets you do that. They get the work; you keep the final say on the bit that matters.