Users & Impersonation
Supervisors can invite users into companies. As an admin, you can manage the entire user pool.
Browsing users
Click Users (opens in a new tab) in the sidebar. You see every user account on the platform, with:
- Name and email
- Role (admin / supervisor / customer)
- Active/inactive status
- Companies and teams they belong to
- Last sign-in time
Creating a user
Click New user (opens in a new tab) and fill in the form. You can pre-assign role and company memberships. The user receives an invitation email and proceeds through the standard onboarding flow (Signing In).
Editing a user
Click into a user's row. From their profile you can:
- Change name and email
- Change role (carefully — role changes have wide implications)
- Re-send their invitation
- Trigger a password reset
- Disable their 2FA (use this when a user is locked out and has lost their recovery codes)
Deactivating a user
Use Discard on a user record to deactivate. They lose access immediately. The account record is preserved for audit purposes — you can Undiscard to restore.
Outright deletion of users is not a normal admin action; reach out to engineering only if a regulatory request requires it.
Impersonation — becoming another user
Impersonation lets you sign in as another user to see the portal exactly as they see it. Use this for support — debugging "the dashboard isn't showing my calls" complaints, verifying access, etc.
Becoming a user
- Open Users (opens in a new tab) in the sidebar.
- Find the target user.
- Click Become on their row.
- The portal switches your session to that user. You'll see a clear banner reminding you that you're impersonating.
While impersonating:
- Every action you take is recorded as that user's action (with a marker indicating it was an admin)
- You see only what they see
- Don't change settings or send communications as them unless explicitly authorized
Stopping impersonation
Click Stop impersonating in the banner (or under the user menu). You're returned to your admin session.
When NOT to impersonate
- To bypass an access control issue you should fix instead
- To act on a customer's behalf without their knowledge
- For long debugging sessions when reading the audit log would suffice
Auditing changes
The portal preserves a full audit trail of who changed what, when, on the records that matter most.
What's audited
Audit trails are kept for changes to:
- Users — email, role, active status, deactivation
- Companies — every meaningful field
- Organizations — every meaningful field
- Company memberships — who was added, who was removed, role changes
- Inbound numbers — additions, edits, deactivations
- Call recordings — updates after the fact
- Playbooks — every version is preserved (separate from the audit log, see the playbook page itself)
Reviewing audit trails
Most record detail pages have a History or Activity section showing changes to that record. You'll see:
- Who made the change
- When
- What field changed (before → after)
- Whether the change was made directly or via impersonation
For deeper queries (e.g., "show me every change to billing across the last 30 days"), engineering can query the audit data directly.
Why this matters
When a customer disputes "we never agreed to that rate," or "I never added that phone number," the audit log is the source of truth. Treat it like accounting records.
Disabling 2FA for a locked-out user
When a user is locked out and has lost their recovery codes:
- Verify their identity through an out-of-band channel (don't trust the email — that may be compromised).
- Open their user record.
- Use the Disable 2FA action.
- Inform them they should re-enable 2FA after logging in.
- Note this in your support records.
Next
- Security — IP restrictions, captcha, 2FA enforcement
- On-call Playbook — common user-access incidents