Settingsbeginner

What are Users?

Users are the people with access to your Atender workspace. Each gets a login, exactly one role, and optional team membership. Onboarding is invitation-based; deactivation preserves their history rather than deleting it.

4 min read

What are Users?

Users are everyone with login access to your Atender workspace — the five standard roles are Owner, Team Lead, Agent, Reader and Analytics. The user system covers invitation, role assignment, team membership, and account lifecycle (active / inactive / deleted).

What a user has

  • Email — Login identifier. Unique across the whole platform, not just your workspace — the same address cannot hold two Atender accounts.
  • Full name — The user’s real name
  • Display name — The name shown to callers and teammates (often the same as full name)
  • Role — Exactly one role. Assigning a role replaces the previous one; a member can also sit with no role, which the list shows as No role assigned.
  • Team(s) — Optional team memberships — users can belong to multiple
  • Active status — Currently enabled or deactivated
  • Beta access — Availability depends on the active tenant. Any personal beta flag is treated separately and globally where applicable.

When a user belongs to multiple workspaces, beta-only onboarding and feature-request gates are evaluated for the tenant they are currently using.

Inviting users

Users join an existing workspace by invitation:

  1. An admin enters the new user’s email address and picks a role. Those are the only two fields — the invitee supplies their own display name when they accept.
  2. Atender records the invitation and, if Send invitation email automatically is left on, emails the person a link. No account exists yet at this point.
  3. The invited user opens the link, sets a display name and password, and lands in the workspace with the role they were given. The account is created at this step.

Joining an existing workspace is invitation-only: every workspace member must be invited by someone who holds the invite permission. The link is one-time and expires after seven days; an expired invite cannot be reissued in place — revoke it and send a new one.

Where public trial signup is enabled, it does not add the person to an existing workspace. Instead, after email verification, Atender creates a new trial workspace for that user.

See Invite a user for the full flow.

Active vs inactive

Users can be deactivated within a workspace without being deleted. Deactivated users:

  • Can’t log in to that workspace
  • Don’t appear in default user lists (separate “Inactive” tab)
  • Retain their conversation history, notes, and audit trail
  • Can be reactivated at any time by a workspace admin

This is the right path when someone leaves the team, takes long leave, or temporarily shouldn’t have access. See Deactivate or reactivate a user.

Workspace activation is separate from a user’s platform-wide sign-in status. An otherwise active workspace member can still show a Sign-in blocked badge in Settings → Users if their global account has been disabled. Workspace admins can manage workspace activation and deactivation, but platform-level sign-in blocks require superadmin or support action.

Beyond deactivation there is Delete from tenant, offered only once a member is already deactivated. It removes the membership and their role assignments — their work in conversations, comments and analytics stays attributed to them, and their platform account is untouched. There is no “delete the user account” action on this screen.

Owner protection

An Owner is protected in two different ways, and it is worth keeping them apart:

  • Any owner, last or not, cannot be deactivated or removed from the workspace. Both attempts fail with “Cannot deactivate an owner. Change their role first.” / “Cannot remove an owner.” Change the role first, then deactivate or remove.
  • The last owner’s role cannot be taken away“Cannot remove the last owner. Assign another owner first.” Note that only an existing owner can grant the Owner role.

The workaround when transferring ownership: assign Owner to a second user first, then make the change.

What’s NOT supported today

A few things to set expectations:

  • SSO / SAML — not currently. All users authenticate via email + password (managed by Supabase auth under the hood).
  • Public signup into existing workspaces — joining an existing workspace is invitation-only.
  • Cross-tenant accounts — a user in Tenant A is not automatically a user in Tenant B. Each tenant has its own user list.

Two-factor authentication

Users can enroll TOTP factors for two-factor authentication. Requiring MFA workspace-wide is an Owner-only decision — it is deliberately not a permission that can be handed to a custom role — and superadmins can additionally be covered by a separate platform-wide requirement. Both enforcement switches default off and must be deliberately enabled.

For most teams, the limitations don’t matter day-to-day. They become relevant when integrating with corporate identity providers or scaling across many regions / business units.

Invitations

Invites appear under the Invitations heading above the Active / Inactive tabs, each with a Pending, Expired or Accepted badge. Each row shows the recipient’s address, the role they were invited to, and the date the invite expires (or was accepted). From here you can:

  • Copy Link — grab the invite URL to send it yourself
  • Revoke it, via the trash icon on the row

There is no resend action. If an invite expired or went missing, revoke it and send a fresh one.

Where to start

Tags

Getting StartedConcept