The demo account is treated as the vendor's own

A demo account flagged as the vendor's own is exempted from the per-business rules that only make sense for a real company, and every destructive demo operation refuses to run against anything else.

What it is

One flag on the account row, checked by a small module that answers 'is this org an extension of the vendor rather than a customer'. It drives exemptions — most visibly, the demo sends on the vendor's own messaging account and registered brand rather than needing a legal entity of its own — and it is the interlock that makes seed and wipe operations safe to expose as buttons.

Also called: demo account · sandbox account · sales demo · test tenant

See it
The demo account is treated as the vendor's own
Area
Platform & Admin
Group
Tenancy & isolation
System
Multi-Tenancy & Identity
Solves
3 named problems
01isAgencyOwnedOrg() returns true for the platform's own account id or for any account carrying the demo flag.
02agencyOwnedReason() supplies the explanation for UI that has to justify the exemption.
03Seeding and wiping both refuse to run against an account that isn't flagged.
The account roster with a rectangular DEMO badge next to one row and the demo panel's seed/wipe controls with their interlock warning. src/app/platform/clients/page.tsx and src/components/platform/tenant/DemoPanel.tsx. Sample data — no customer information appears here.
How it works
  1. 1isAgencyOwnedOrg() returns true for the platform's own account id or for any account carrying the demo flag.
  2. 2agencyOwnedReason() supplies the explanation for UI that has to justify the exemption.
  3. 3Seeding and wiping both refuse to run against an account that isn't flagged.
  4. 4Every seeded delete is scoped by both the account and a distinctive id prefix, so nothing outside what the seeder created can be touched.
  5. 5Outbound messaging is parked off for the demo account at creation, with invalid-domain addresses as a second belt.
Why we built it

The module quotes the instruction it implements, Keith 08-22: a demo account 'is not a real business. It is part of the CYA / Leads 2 Build entity — a sub-account we use to demo… an extension of the agency's assets, not an individual sub-account… and this is the ONLY sub-account that gets treated this way.' The telephony consequence is spelled out: the model assumes each account is a different business with its own carrier registration verified against public records, and for an invented company 'it is not just unnecessary, it is impossible… There is no EIN to give.' The test is the flag rather than a hardcoded id for a stated reason: 'an org cannot be safe to wipe but unsafe to treat as agency-owned', and a customer account could never carry the flag because 'giving a customer org is_demo would already hand the seeder permission to erase their data.'

The problem
  • A demo account can't complete carrier registration because the business doesn't exist.
  • Seed and wipe operations are dangerous unless they can only ever touch demo data.
  • A demo full of invented people must not send real messages.
Sound familiar?
What you get
Prospects see a fully populated account without touching a customer's data.
Destructive demo operations are structurally unable to reach a real account.
The demo sends under the vendor's own registered brand, which is accurate.

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 →