Users and teams
Path: /admin-settings → Users and Teams tabs
Platform-wide management of user accounts and teams. Distinct from Team settings → Users, which scopes to a single team.
Why the user views and forms differ
Settings → Users and Admin settings → Users have different scopes. This is expected, including when the same Super Admin opens both pages.
| View | Scope and role displayed | What the form manages |
|---|---|---|
Settings → Users (/settings) | Memberships of the selected team; Team Admin (ADMIN), Member (MEMBER), Viewer (VIEWER). | Membership and role in that team. |
| Admin settings → Users, opened by a Super Admin | Platform accounts; Platform role shows Standard User (USER), Super Viewer (SUPERVIEWER), or Super Admin (SUPERUSER); memberships are shown separately. | Account creation, ordinary-account profile/status and team assignments; a separate challenged action changes platform roles. |
| Admin settings → Users, opened by a Team Admin | Memberships in teams that administrator manages. | Team membership actions within that authority; no platform-role elevation. |
A Super Admin can still have a Team Admin membership badge in the team list. That badge describes their membership in that team; check Platform role in Admin settings to determine platform privileges. A Team Admin does not gain Super Admin authority by having the same team badge.
SUPERUSER is deliberately absent from the team-role selector. To add another Super Admin, use the workflow below. Console recovery is only needed when normal privileged access is unavailable.
Example: the same account in both lists
Suppose Alex is a Standard User at platform level and Team Admin in the Operations team. Settings → Users shows Team Admin. Admin settings → Users shows Standard User in Platform role and Operations (Team Admin) in memberships, within the viewing administrator's authority.
Another Super Admin promotes Alex to Super Admin. The platform-role column changes after verification; the Operations membership stays Team Admin. Opening Settings → Users can therefore show the same team badge as before, even though Alex now has platform-wide authority.
If Alex is later demoted to Standard User, the Operations membership is still retained. Alex consequently remains a Team Admin in Operations. To remove that team authority too, change or remove that membership separately. Demotion of the platform role does not remove all team access.
Users tab
| Column | Description |
|---|---|
| First / Last Name | The user's name. |
| Login email. | |
| Platform role | Standard User, Super Viewer, or Super Admin. Changing Super Viewer or Super Admin sends an email challenge. |
| Active | Whether the account can log in. |
| Teams | Team memberships and their roles, limited to the teams the acting administrator can inspect. |
Management
- Create user — name + email; assign to teams with roles. The user receives a welcome / password-setup email if mail is configured.
- Edit user — name, email, active status, team memberships for Standard Users; demote privileged accounts first as described below.
- Platform role — Super Admins can promote or demote Super Viewer and Super Admin. The acting Super Admin confirms a one-time code sent to their own account email. The affected user receives a separate role-change notification after success. Super Viewer is platform-wide read-only — see Roles and access.
- Default team — which team is auto-selected on login.
- Deactivate — set active = false. The user can no longer log in.
Teams tab (SUPERUSER)
| Column | Description |
|---|---|
| Name | Team name. |
| Base Numbers | Assigned base numbers. |
| Apps | Number of apps in the team. |
Team configuration
| Field | Description |
|---|---|
| Name | Unique team name. |
| Base Numbers | Multi-select of base numbers the team can use for PSTN endpoints. |
| Users | Members with roles (ADMIN / MEMBER / VIEWER). |
| Server Groups | Multi-select of server groups available to this team. |
| Recording Enabled | Default for team's apps (can also be toggled per-app). |
| SMS Enabled | Whether SMS features are available (default true). |
| Notifications | JSON config — thresholds and recipients. |
Teams support soft deletion — deactivated teams carry a Deleted At timestamp and are excluded from active lists. New teams may be provisioned with a default dashboard / example app depending on deployment settings.
API access configuration
Controls how the team uses API keys:
| Field | Description |
|---|---|
| Allowed API Scopes | Multi-select (e.g. CREATE_CALL_TOKEN, READ_CALL_TOKEN). |
| Max API Keys | Max keys the team can create (default 2). |
| Max Requests Per Day | Daily rate limit per team. null = unlimited. |
Sync all apps
Pushes every app config in the team to Redis. Useful after platform-wide changes (e.g. server group config) or to recover from drift.
SUPERUSERs review authentication and role-management audit events on the dedicated Access logs tab (/admin-settings/access-logs).
Workflows
Create a user
Click Create, enter name + email, assign team memberships with roles, set a default team, save.
Add a Super Admin or Super Viewer
- Sign in as an existing Super Admin and open Admin settings → Users (
/admin-settings). Team Admin access is insufficient. - Find the target by their exact login email. If necessary, create a Standard User first and have them complete password setup or link their enabled corporate sign-in method. The account must be active, unlocked, and usable for sign-in.
- On that user's row, choose Change role → Super Admin or Super Viewer. Review the target and previous/new roles in the dialog.
- Start the change. A six-digit code is sent to the acting Super Admin's existing account email, shown masked in the dialog.
- Enter the code in that same signed-in session and confirm within five minutes. The code is single-use; resend becomes available after 30 seconds and does not extend expiry. Five incorrect attempts exhaust the challenge.
- Confirm the new Platform role in the list. The affected user must sign in again; team memberships are retained. A separate email notifying that user of the role change is queued after success.
- Verify the successful change in Access logs, including the actor, target, previous/new roles, and time.
The code confirms the administrator performing the action. Do not ask the affected user to supply it. A queued notification is not proof of mailbox delivery; investigate missing email in Job history and Ops email delivery.
What each participant should see
| Stage | Acting Super Admin | Affected user | Evidence of completion |
|---|---|---|---|
| Before the request | Can open the target's Change role action and inspect old/new roles. | Keeps the existing role and session. | Record the intended target email and transition. |
| Challenge requested | Receives the code at their own trusted account email and enters it in the original session. | Does not confirm the actor's code. | A started challenge proves only that verification began. |
| Confirmation succeeds | Sees the success result and updated platform-role badge. | Existing sessions are invalidated; signs in again with the existing enabled login method. | Successful role-change audit plus the new persisted role. |
| Notification delivery | Can investigate the associated Tasker delivery if needed. | Receives a separate message describing the role change. | Job transport success and mailbox delivery are checked separately. |
If confirmation returns an error or the browser disconnects, inspect the current platform role and the audit outcome before starting another request. A notification delay does not establish that the role change failed.
Acceptance check for provisioning
Use a disposable test account and two usable Super Admin accounts in the test environment:
- Record the test account's initial platform role and team memberships, and sign in with it in a separate browser session.
- From the acting Super Admin session, promote that account. Confirm the code goes to the actor, not the target, and that no change takes effect before successful verification.
- Confirm the target's previous session no longer authorizes access. Sign in afresh and verify the expected platform access and retained memberships.
- Review the successful event in Access logs and the target notification. Record identities, timestamps and event/job references; do not record the verification code.
- Demote the target and verify fresh-login access is limited to its retained team memberships. Check the second successful audit and notification.
- Verify unavailable/denied actions as appropriate: self-role change, attempts by a Team Admin or Super Viewer, expired/incorrect codes, and editing a privileged account without demoting it. Do not remove your final usable Super Admin merely to test a guard.
Production provisioning uses the same workflow; the disposable-account exercise is release/acceptance evidence, not a prerequisite to repeat for each real user.
Demote or edit a privileged account
Use the same Change role workflow to select Standard User or another permitted platform role. Self-promotion and self-demotion are blocked. The final usable Super Admin cannot be demoted; verify another Super Admin can sign in first.
A Super Admin or Super Viewer must be demoted to Standard User through the challenged workflow before using the ordinary account edit, deactivate, or delete actions. To retain privileged access after editing, promote the account again with a new challenge.
If the change is unavailable or fails
| Symptom | Action |
|---|---|
| Only Team Admin / Member / Viewer appear | You are editing a team membership. Open Admin settings as a Super Admin. |
| No platform-role action on your own row | Another Super Admin must perform the change. |
| Target cannot be promoted | Check active/lock/suspension state and that an enabled sign-in method is set up; resolve ambiguous corporate identity bindings with operations. |
| No verification email | Check the masked acting administrator address, resend countdown, and Tasker delivery/readiness. The role does not change until confirmation succeeds. |
| Expired code or attempt limit reached | Close the dialog and start a new challenge when the rate limit permits. Keep the same session throughout confirmation. |
| Target still sees old permissions | Have the target sign in again after the role change. |
| No usable Super Admin remains | Follow Regain superuser access; do not use direct database role edits as normal provisioning. |
Create a team
(SUPERUSER) Teams tab → Create → name → assign base numbers → add users with roles → configure API access if needed → assign server groups → save. Default dashboard / example app provisioning may run automatically.
Enable API access for a team
Edit the team → API Access Configuration → select scopes, max keys, optional daily limit → save. The team's ADMINs can now create keys in Settings → API Keys.