Support can open your account to help

Vendor staff who hold the enter-accounts capability can open a customer's account and work in it — with money masked, every visit recorded, and a one-click way out.

What it is

An impersonation flow driven by a URL parameter that becomes a sticky session cookie. The middleware forwards the requested target; the server layer refuses to honour it unless the requester actually holds the capability. Inside the account the staff member acts with a tenant role derived from their platform role, with the money mask applied, and every entry is recorded.

Also called: impersonation · open as · act as this account · vendor enters my account

See it
Support can open your account to help
Area
Platform & Admin
Group
Vendor access
System
Multi-Tenancy & Identity
Solves
3 named problems
01?as=<accountId> is read by middleware and persisted as an eight-hour cookie so navigation keeps the account active.
02?as=clear deletes the cookie.
03serverAuth honours the target only for the owner or staff holding tenants.impersonate; for everyone else it is ignored.
The account row's split Open button in the platform console, and the resulting tenant dashboard with the exit affordance in the sidebar. src/components/platform/OpenAsButton.tsx. Sample data — no customer information appears here.
How it works
  1. 1?as=<accountId> is read by middleware and persisted as an eight-hour cookie so navigation keeps the account active.
  2. 2?as=clear deletes the cookie.
  3. 3serverAuth honours the target only for the owner or staff holding tenants.impersonate; for everyone else it is ignored.
  4. 4Entering the account is recorded as an activity row naming the account and how it was entered — open-as, subdomain, or session.
  5. 5The impersonate endpoint records the reason and returns the URL the console should open.
  6. 6The tenant role inside the account derives from the platform role rather than being granted flat.
Why we built it

The capability exists because the previous state was worse in both directions. As the serverAuth comment puts it: 'Support and Sales are supposed to go INTO the account they look after — to fix something, or to walk a new customer through the product they just bought. Before this, only the hardcoded owner could, so an invited rep opening a tenant was treated as a stranger signing up.' The capability is separated on purpose: 'deliberately its own capability, so can go into an account stays a separate decision from can change what they pay.' And the consequence is stated honestly rather than glossed: 'Note what this necessarily means: inside a tenant they see that tenant's books, because they are seeing that tenant's app. It does not give them the PLATFORM's revenue.'

The problem
  • Only one hardcoded person could enter an account to help.
  • 'Can help inside an account' and 'can change what a customer pays' were the same grant.
  • There was no record of who entered an account or why.
Sound familiar?
What you get
Support fixes things inside your account instead of talking you through it.
Entering an account and changing its billing are separate permissions.
Every entry is on the record with the account and the route in.
What's inside

See it on your own jobs

Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.

or keep browsing features →