Skip to main content
This page is for admins with the write:invitations or write:users permission. It covers adding a Support User, blocking and unblocking, listing, the permissions involved, and how Support User activity is audited.

​
How a Support User becomes bound

There are two ways a Support User becomes bound to your organization:
  1. An admin invites them. Someone with write:invitations adds the engineer through the support-user API (below). This is the default path for planned engagements.
  2. An e6data engineer self-binds. For incident response, an authenticated e6data engineer (@e6x.io / @e6data.com) can self-bind to your organization. A self-bind is rejected if your organization has previously blocked that specific engineer - your block decision is always respected.
Either path produces the same result: the user is marked as a Support User in your tenant, an alias is allocated, an audit entry records the bind, and the account syncs to every workspace automatically (typically within about 30 seconds), where it is granted the configured support role so the engineer can debug effectively.

​
Add a Support User

The engineer is now bound to your tenant. The returned email is masked as [email protected], and isSupportUser is true. The same masking applies anywhere this user appears.

​
Block a Support User

A block is the fast revocation mechanism. It preserves the user’s roles (so you can restore access by unblocking later) but immediately denies them entry to your organization.
  • The block is per-tenant - it only affects your organization. If the same engineer supports another customer, that relationship is unaffected.
  • A blocked engineer attempting to switch into your tenant is denied with 403 Forbidden.
  • If a Support User is blocked in every tenant they belong to, their login fails entirely with 401 Unauthorized.
  • Self-bind is rejected for any engineer your organization has blocked - even if they were never previously bound.

​
Unblock

The user regains the roles they had at block time and the alias they previously held, if it’s still available; otherwise a new one is allocated.

​
List and inspect

  • GET /api/v1/users/me/tenants - each tenant entry carries isBlocked, so you can see where Support Users are currently active versus blocked.
  • The standard user-list endpoint surfaces isSupportUser: true for every Support User in your organization, with the alias rendered in the email and name fields.

​
Required permissions

These are the same permissions you already manage through your existing roles - no new role bindings are required. See Roles and permissions.

​
Audit and visibility

Every meaningful action a Support User performs is recorded with their alias, not their real identity: For how aliases resolve correctly over time and what is never recorded, see Privacy controls.

​
End-to-end flow

When you add a Support User, the Control Plane validates the email domain (e6x.io / e6data.com), allocates the next free alias for your tenant, binds the user, writes an alias-history record, and returns a customer-facing response as support-N. The binding then syncs to each workspace automatically (within about 30 seconds), where the engineer is granted the support role and all logs and queries are attributed to support-N. When the engagement ends and you block the user, the Control Plane marks them blocked for your tenant (preserving roles), refuses future tenant switches and self-binds, and the workspaces stop accepting the user within one sync cycle.

​
See also

Last modified on October 1, 2026