The Admin Toolbox: Impersonation, Force Release, Stuck-Flow Fixes

The Admin Toolbox is the controlled escape path for tenant issues the regular UI cannot resolve: one tenant, one row, one stuck flow, with a required reason, an audit event and the smallest possible blast radius. None of it is a faster version of normal work. All of it is a break-glass path with a logbook next to the glass.

Impersonation with write-block

The biggest tool. From a user’s detail page at /admin/users/[slug], platform staff start an impersonated session to see the app as that tenant user sees it — no e-mail ping-pong about which button is greyed out. The start requires a reason of at least five characters, the session lasts 30 minutes, and it is read-only: during impersonation every mutating request is refused, server actions refuse to write, and the banner says so. Starting a new session automatically revokes the previous one. Start and stop are both written to the activity log with the reason, so a tenant asking “did somebody from the platform look at our account” gets a row, not a guess. Trade-in customers have their own path from /admin/customers/[id], with the same reason, the same clock and the same write-block.

The one force-complete

Exactly one force-complete exists, and it is for stuck collections: a collection wedged in a non-terminal status shows a platform-only escape hatch on its detail page that pushes it to completion and writes the override to the audit log. Receiving sessions, workflow stages and settlement runs have no such button, on purpose; they resolve through their normal flows, and a force button that nobody needs is a force button somebody will eventually press.

Escrow admin surfaces

Normal deposit confirmation and cancellation at /admin/escrow/pending require two platform owners. The exceptions are available to platform owners and platform staff: cancel a still-pending deposit at least seven days old with a reason of at least ten characters, or approve another person’s deposit-confirmation proposal with a reason of at least twenty characters. /admin/escrow/disputes contains dispute review. /admin/escrow/force-release is owner-only: choose seller, buyer or split, provide a reason of at least thirty characters and repeat the exact escrow number. Split amounts must add up to the escrow total.

Each of these three admin corrections saves its status, applicable approval and accounting lines, dossier event and required audit together. An error leaves the previous state intact. The same actor repeating the same instruction does not create a second correction; existing accounting is not overwritten. Current platform permissions are checked again, and an active impersonation session blocks the action. The operational reason remains in the dossier. A recorded release or refund does not initiate a bank transfer, and forcing a financial outcome does not automatically resolve an existing dispute.

Blancco sync, on demand

Per-tenant Blancco sync runs on a schedule, but a tenant who just connected the integration should not wait for the next tick. The integrations card on /admin/organizations/[slug] shows the connection status and last sync, and a “Sync now” button runs the same code path ahead of schedule.

Stranded users and unverified e-mail

The user detail page is also the recovery bench. It shows e-mail verification status and account state, and offers re-sending the invitation or the verification e-mail, a password reset, suspend and reactivate — all without opening the edit form first. A user who ended up with no healthy organization context is stranded; platform staff recover them into a new organization by entering a name and a slug. Account deletion is an erasure path, not a row delete, and is never available for your own account.

Tenant storage purge

The most dangerous button on /admin/storage is “Purge storage”, and it is owner-only; any other platform role gets a refusal from the server and nothing is touched. The dialog first loads a preview of exactly what would go — unlinked document records, missing-file records and orphaned objects, with counts — then asks for the exact organization name, and only enables the red button when there is something to purge and the name matches. Documents attached to a living business record are never counted and never removed. The outcome is logged fail-closed with the counts; if the log cannot be written, the purge does not run. There is no undo, which is why there is a preview.

audit_events is append-only

The audit_events table has database triggers that reject UPDATE and DELETE, and every row is chained to the previous one with a tamper-evident hash, so a gap or a rewrite shows. New rows can be inserted; the original stays. The Admin Toolbox can fix what is broken. It cannot tidy up what was recorded.