Skip to main content
e6data has three identity types: users (humans), groups (collections of users or service accounts assigned roles together), and service accounts (non-human identities for automation). All three participate in the same role-based access control - see Control Plane vs Compute Plane permissions. Identities and group memberships are managed on the Control Plane and synced to each workspace automatically, typically within about 30 seconds.

​
Users

A user has one global identity but belongs to your organization (and possibly others) with per-organization roles and block status. A user can be Admin in one organization and Viewer in another.

​
How a user joins your organization

  • Invitation. An admin with write:invitations invites the user by email; they accept via a one-time link and pick a sign-in method.
  • First-user bootstrap. The first user of a new organization is automatically assigned the Admin role.
  • SSO just-in-time (JIT). If SSO is configured with domain auto-join, a user signing in with a matching email domain is provisioned on first login with the SSO default role. See Domain auto-join and JIT provisioning.
Invite a user over the API:
Required permission: write:invitations. If roles is omitted, the user defaults to Viewer.

​
Sign-in methods

​
Reaching a workspace

The Control Plane is the source of truth. Each workspace pulls user and group changes automatically (about every 30 seconds), so a role binding that references a user’s email becomes effective once the user is synced - you don’t re-bind after a user appears. Control Plane permissions do not become Compute Plane permissions: a Control Plane admin must still be granted workspace role bindings to do anything inside a workspace.

​
Block and unblock

A block immediately denies a user entry while preserving their roles, so you can restore access by unblocking:
Blocks are per-organization. A user blocked in your org cannot switch into it (403); a user blocked in every org they belong to cannot log in at all (401). You cannot block yourself or the organization owner.

​
Other lifecycle notes

  • Changing an email keeps the user’s underlying identity, so role bindings, audit history, and group memberships continue to work.
  • Removing a user drops their membership; they can rejoin later via invitation.
  • Every change (invited, joined, role added/removed, blocked, removed, profile changed) is recorded with the acting user and timestamp.

​
Groups

A group is a flat collection of users (and, on the Compute Plane, service accounts) assigned roles collectively. Instead of binding each user to a role, bind the group once and manage membership. Groups solve two problems: per-user binding explosion (a 50-person team needing the same access is one set of group bindings, not 50× the bindings) and drift (remove a member once and every workspace updates within ~30 seconds). A group can carry both Control Plane role bindings (org-level APIs) and Compute Plane role bindings (data operations), tracked separately because the permission vocabularies differ. Manage groups over the API:
Groups are flat (no group-of-groups) and per-organization. Adding a member grants them all of the group’s roles across every workspace within ~30 seconds. If you map IdP groups to e6data roles via SSO, membership flows automatically on sign-in.

​
Service accounts

A service account is a non-human identity scoped to a single workspace, used for automation (CI/CD, scheduled jobs). It authenticates with an e6sa_ API key and is governed by the same role bindings as users. Create a service account and issue a key over the API:
The name is permanent (lowercase letters, digits, and hyphens; 1–63 characters). A key’s secret is shown once at creation. Deleting a service account revokes all its keys and removes its bindings. Grant a service account the minimum role it needs, use one per system, and rotate keys with create-before-delete. For the full token lifecycle, see Access tokens.

​
See also

Last modified on October 1, 2026