Unit Transfers is a dedicated HQ screen for a franchise-lifecycle event nothing else in SalesThumb models: an existing franchisee selling their shop to a new owner. It's separate from ending a franchise agreement — a unit transfer hands the relationship to a new owner rather than terminating it. You'll find it at HQ dashboard → Network → Unit Transfers (`/app/hq/[orgId]/unit-transfers`), right alongside Locations, Users, Documents, and Agreements. This is an HQ-level page for the franchisor side of the org — it isn't part of an individual shop's own settings, and deciding a request specifically requires an Owner or Admin role (see Things to know below).
Requesting a transfer
Click Request transfer (top right of the Unit Transfers page) to open the request form:
- Shop — which location is changing hands.
- Current owner (optional) — name and email of the outgoing franchisee, if you have it on file.
- Proposed new owner — name and email of who's buying the shop; both required.
- Requested / target closing date — required.
- Notes (optional) — deal terms, reason for sale, or anything else worth recording.
Submit request creates the record in Requested status. Filing the request itself only requires HQ dashboard access for the org — not the admin role that reviewing and deciding it needs — since this step is meant to be franchisee-initiated (an HQ admin can also file it on the franchisee's behalf).
A shop can only have one open transfer request at a time. If a location already has a request sitting in Requested, HQ Reviewing, or Approved status, opening a second one is blocked with a message to complete or reject the existing one first. A Rejected or Completed request doesn't block a new one — a shop can genuinely change hands more than once over its life.
HQ review: start review, approve, or reject
Every request shows up in the list on the main page — shop name, status badge, current owner → proposed owner and their email, and the requested date — and a banner at the top of the page counts how many are currently sitting in Requested or HQ Reviewing, awaiting a decision. Click a row (or its Review button) to open the detail dialog.
While a request is in Requested or HQ Reviewing status, the dialog gives you a reviewer note field and up to three actions:
- Start review — only available from Requested; moves it to HQ Reviewing to flag it as actively being worked.
- Approve — moves it to Approved. Available directly from Requested or from HQ Reviewing; you don't have to start a review first.
- Reject — moves it to Rejected. Also available from either status.
Whatever note you type when you click Start review, Approve, or Reject becomes the request's current reviewer note, replacing whatever was there before — there's one latest reviewer note per request, not an appended history of each decision. If the request's status has already moved on by the time your action lands (someone else acted on it first), the update is refused with a conflict message instead of silently overwriting.
Completing a transfer
Once a request is Approved, the detail dialog shows a completion panel with an optional completion note and a Mark completed button. Completing it sets the record to Completed and closes it out.
Marking a transfer complete does not itself reassign the shop's ownership, team membership, billing, or logins to the new owner — that hand-off is still a manual step you do outside this workflow. The completion note is a reasonable place to record what you actually did (e.g., when membership was reassigned), since there's no separate field tracking that.
Things to know
- HQ-level feature. Unit Transfers lives inside the HQ dashboard for the org (Network group in the sidebar) and requires the org to have the HQ add-on enabled — it isn't something an individual shop sees in its own navigation.
- Requesting a transfer requires HQ dashboard access for the org (the same access needed to open this page at all) — it does not require the admin role.
- Reviewing, approving, rejecting, and completing a transfer requires the Owner or Admin role on the org.
- One open request per shop. A location can have only one request in Requested, HQ Reviewing, or Approved status at a time; Rejected and Completed requests don't block filing a new one for the same shop.
- Completing is record-keeping only. It doesn't reassign shop ownership, team membership, billing, or logins for you.
- Single current reviewer note. There's no running history of every review action — only the latest note is kept per request.
- You can filter the request list by status (All, Requested, HQ Reviewing, Approved, Rejected, Completed).
Frequently asked questions
Q: Who can request a unit transfer?
A: Anyone with HQ dashboard access for the organization — it doesn't require the Owner or Admin role that reviewing and deciding a request needs. Requesting is meant to be the franchisee-initiated step, though an HQ admin can also file it on the franchisee's behalf.
Q: Who can approve or reject a transfer request?
A: Only someone with the Owner or Admin role on the org. Starting a review, approving, rejecting, and marking a transfer completed are all gated behind that same admin-level requirement.
Q: Does approving a transfer actually move the shop to the new owner?
A: No. Approving and completing a unit transfer request only updates the record's status — it doesn't reassign the shop's team membership, billing, or logins. That handoff is still done manually outside this workflow.
Q: Can I open a second transfer request for the same shop?
A: Not while one is already open. A shop can only have one request in Requested, HQ Reviewing, or Approved status at a time — filing a second is blocked until the existing one is completed or rejected. A shop with a prior Rejected or Completed request can have a new one opened.
Q: What's the difference between "Start review" and just clicking "Approve" or "Reject"?
A: Start review is optional — it just moves a request from Requested to HQ Reviewing to mark it as being actively looked at. You can approve or reject directly from Requested without going through that step first.
Q: Can I see a history of every review decision made on a request?
A: No. The reviewer note field holds only the latest decision's note — it's overwritten each time a review action is taken, not appended to a log.