Users

Organization membership is managed from Settings → Users. From this page an administrator invites new people by email and removes people who should no longer have access. In Enterprise Edition the same page assigns each account an organization role and changes it later.

---

The Users page

The header reads Users, described as "Manage organization users: invite or delete users.", with an Invite User button on the right. Below it, existing users are listed:

When there are more users than fit on one page, pagination controls appear in the footer. If no users match, the table shows No users found.

Invite a user

1. Click Invite User. The dialog explains: "Enter the user email. A strong password is pre-generated according to the security rules. This password will be included in the invitation email."
2. Enter the Email address.
3. A Password is generated for you and shown read-only. Regenerate produces a different one. The rule beneath the field states it: "Password must be at least 8 characters and include at least 1 uppercase letter and 1 number."
4. Choose a Role. The options come from the organization's configured authorities; the first one is preselected. This step is Enterprise Edition only - Community Edition shows no Role field and invites every account as an administrator.
5. Click Invite.

The Invite button stays disabled until an email address is set and the generated password satisfies the password rules; in Enterprise Edition a role must be chosen too. An invalid role is rejected before any account row is created, so a bad request cannot leave an orphaned user behind.

The invitation email carries a link to /activate?key=…. Until the invitee follows it the account is not activated, so it shows Pending in the table; following the link flips it to Active. Inviting an email address that already has an account is rejected.

An invited account occupies a seat against the deployment's member quota from the moment the invitation is sent, not from the moment it is claimed.

Change a user's role

1. Click the edit (pencil) icon on the user's row to open the Edit User dialog, described as "Change the user role."
2. The dialog shows the selected User (their email) and a Role dropdown set to their current role.
3. Pick a new Role and click Save.

Only the organization role is editable here - email and name are not. Workspace roles are managed separately, per workspace.

Remove a user

Click the delete (trash) icon on the row and confirm. The confirmation warns that the action cannot be undone. Removing a user revokes their access to the organization.

What differs between editions

Community Edition has one level of access. There is nothing to assign, so the controls that would assign it are absent rather than disabled:

The workspace role model below - roles, permission scopes and per-workspace membership - is Enterprise Edition throughout, and each section carries the badge.

---

Roles and permissions

Enterprise Edition

ByteChef separates two things that are easy to confuse:

• The organization role (ROLE_ADMIN / ROLE_USER) - the authority assigned on this page. It governs the administrative surfaces: Settings pages, user management, licensing.
• The workspace role - assigned per workspace, and what governs day-to-day work on projects, workflows, connections, and data.

Permissions are scoped to workspaces. There are no per-project roles and no per-resource ACLs: a user can be an admin in one workspace, an editor in another, and have no access at all to a third.

The built-in workspace roles

Enterprise Edition

The roles are ranked rather than enumerated: a role is granted every permission scope whose declared minimum role it is at least as privileged as, so VIEWER ⊆ EDITOR ⊆ ADMIN holds by construction. Adding a scope means declaring its minimum role once, not editing three role definitions.

Permission scopes

Enterprise Edition

Scopes are contributed per module at startup rather than listed in a central enum. The built-in set and its minimum role:

Declaring the same scope name with two different minimum roles fails the application at startup rather than silently picking one.

Managing workspace membership

Enterprise Edition

Workspace membership has two surfaces. The current workspace's members are managed on its own page, Settings → Current Workspace → Users. To reach another workspace's members without switching to it, use Settings → Workspaces: each workspace row's ⋮ menu has a Members entry that opens the Workspace Members dialog. The dialog lists members with User, Role, and Added columns. An admin changes a member's role inline through the Role dropdown, removes a member with the trash action, and adds one through the Add user row - search by email, pick a role, confirm. The role dropdown is derived from the server-side role enum, so a role added server-side appears without a client change.

Only a workspace Admin sees the role dropdown, the remove action, and the add row; everyone else sees the membership list read-only. Removing a user at the workspace level revokes their access to every project in that workspace at once.

Federated identity

Enterprise Edition

If you federate authentication through an external identity provider, group claims can drive workspace roles automatically. See Identity Providers.

What gets logged

Enterprise Edition

Membership and role changes are recorded in the audit log as WORKSPACE_USER_ADDED, WORKSPACE_USER_REMOVED, and WORKSPACE_USER_ROLE_UPDATED; account lifecycle as USER_CREATED, USER_ACTIVATED, USER_PASSWORD_CHANGED, and USER_DELETED.

See also

• Workspace Users - the per-workspace membership view.
• Identity Providers - federating identities instead of inviting local accounts one by one.