For super admins
This is the internal operations guide for TrueTone staff supporting enterprise customers. A super admin is not a customer role: you operate across organizations to support, troubleshoot, and administer, which is why this page carries the strictest rules in the product.
What it is
This page covers what you can do as TrueTone staff, how the guardrails work, and, just as important, which levers deliberately don’t exist so you don’t go looking for them.
With the reach to touch anyone’s account comes the strictest rule set in the product. The governance described below is not policy you’re asked to follow; it’s enforced in the system itself.
Who it is for
TrueTone staff. A super admin operates across organizations to support, troubleshoot, and administer; it’s not a role any customer holds. Sales, marketing, and product teams should also read this page before promising a customer what support can or cannot do on their behalf.
How it works
Impersonation is the main tool, used under the doctrine
Most support starts by seeing what a customer sees. You can step into any user’s account except another super admin’s. Impersonation here is governed, and the governance is enforced in the system, not just policy. Four rules apply every time.
Declare the mode when you start
Choose view only (you can look; you can’t change anything) or act on behalf (you can make changes). Default to view only: it answers the large majority of support questions and makes it impossible to fat-finger a change into a customer’s live account. Only choose act on behalf when you actually intend to fix something.
State a real reason
Boilerplate is rejected. “User support and troubleshooting” will not be accepted; write what you’re actually doing and why. This becomes a permanent record, so make it useful to whoever reads it later.
Know that everything you do is attributed to you
The trail reads “you, acting as the user, because the reason you stated.” You cannot act anonymously through someone’s account.
Respect the blocklist
The blocklist below holds even in act on behalf mode. There is no exception for it.
What you can never do through a borrowed identity
Even in act on behalf mode, these are blocked, because they have no legitimate “on behalf” story and can’t be undone:
- Money. Invoice top-ups, the billing portal, buying credit packs. Do these as yourself, where the record names you.
- Identity and security. Passwords, MFA, roles, and impersonation-from-inside-impersonation. Altering an account while wearing its owner’s identity is a takeover.
- The user’s voice. You may use a loan officer’s cloned voice (to reproduce an issue, to generate a sample); you may not re-record, retrain, or delete it.
The compliance line that matters most. Because the enterprise pitch is compliance, the blocklist specifically prevents making a loan officer’s own compliance sign-off as them. A borrowed identity must never be usable to forge the attestation the whole product exists to make trustworthy.
The audit trail
Every impersonation session, and every action taken during one, is recorded with the real actor attributed. Two things worth knowing:
- The record survives user deletion. If a user is later deleted, the impersonation history that named them is preserved (it carries its own identity snapshot). An audit trail you can erase by deleting its subject is not an audit trail; this was specifically fixed.
- Refusals are recorded too. If the blocklist stops an action, that attempt is logged. “What did they try to do” is exactly what an auditor asks.
You can review impersonation sessions in the super-admin security views.
Provisioning support
Org admins provision their own loan officers (single add or bulk CSV). When you’re helping:
- Seats activate and bill on onboarding completion; an invited-but-not-onboarded person is not yet a billed seat. If a customer’s seat count looks off, check who has actually completed onboarding.
- The Mortgage License (NMLS and licensed states) is org-attested. Loan officers can’t self-edit it, by design. Changes go through the org admin, or through you on their behalf, under the doctrine above.
- Bulk CSV is header-aware and carries license fields. If an import looks wrong, check the header row and quoting (multi-state cells look like
"CA,TX").
Good to know
Levers that deliberately don’t exist. Save yourself a search; these are intentionally not built, and their absence is a decision, not a gap.
- Org-level suspend or terminate. There is no working “suspend this whole organization” or “terminate this account” button. Earlier ones existed as dead UI (no backend) and were removed rather than left to look functional. The real levers are per-user suspension and cancelling the Stripe subscription. If a customer needs an org shut off, that’s how, not a single button.
- Distributing finished content. Admins distribute seeds (topics), never finished posts. This is permanent (ADR 0032): fifty people publishing identical text is the exact outcome the product exists to prevent.
- A multi-level branch, region, or division hierarchy. An older aspirational spec described one; it isn’t built. The live model is flat: an organization with seats and admins.
The Compliance Gate is staged, not live. Pre-publish compliance checking, with TrueTone enforcing and TrueComply reviewing, is designed and contracted but staged, rolling out channel-by-channel in advisory mode as TrueComply is wired in. It is not blocking content today. Coverage levels (off, advisory, enforced, always-review) are authored by a compliance reviewer in TrueComply, not by marketing, so an organization can’t weaken its own oversight. When supporting a customer, don’t represent the Gate as live and blocking; it isn’t yet.
Watch-outs from the audit
Things that were fixed but are worth carrying in your head when something looks odd:
- A loan officer’s billing page shows only their own usage. If a customer says they can see colleagues’ activity, that’s a regression; escalate it.
- Credit requests from loan officers notify the org admins. If an admin says “nobody told me,” check whether the org has an active admin to notify.
- Custom-domain verification accepts both a root-domain and a subdomain setup. If a Tier-1 site won’t verify, it’s not the “wrong record type” story it used to be.