> For the complete documentation index, see [llms.txt](https://docs.atomyx.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.atomyx.io/atomyx-vault/users-groups-and-roles.md). # Users, Groups and Roles ## Overview {% hint style="info" %} **Prerequisites:** Before using this guide, read the Atomyx Vault Overview for background on identity management and the role-based access model. {% endhint %} Atomyx Vault provides a multi-level access control system that governs who can access workspaces, products, and specific features within the Atomyx platform. Access is managed through a combination of workspace-level roles, product-level roles, and groups. This document covers the management of users, groups, and the role hierarchy at both the workspace and product levels. ## User Types Atomyx Vault distinguishes between three user types. These types define the scope of a user’s administrative capabilities across the platform.

User Type	Scope	Description
Super Admin	Platform-wide	Has access to all workspaces and all administrative functions across the entire Atomyx Vault installation. This type is reserved exclusively for Atomyx employees and cannot be assigned to customers.
Account Admin	Workspace-wide	Has full administrative access within a specific workspace, including the ability to manage users, products, groups, and settings.
Regular User	Varies by role	A standard user whose access is determined by their workspace role and product-level role assignments.

{% hint style="info" %} **Note:** Super Admin is a platform-level property, not a role. It is set by other Super Admins and is not visible in the regular workspace role management interface. Account Admin status is similarly a property rather than an assignable role. {% endhint %} ## Workspace Roles Every user in a workspace is assigned exactly one workspace-level role. The role determines what the user can do within the workspace context.

Role	Manage Settings	Manage Products	Manage Users	Manage Groups	Manage Billing	View Products
Owner	Yes	Yes	Yes	Yes	Yes	Yes
Admin	Yes	Yes	Yes	Yes	No	Yes
Member	No	No	No	No	No	Yes (if granted)
Billing	No	No	No	No	Yes	Yes (if granted)

### Owner The Owner role has full administrative control over the workspace, including all management capabilities and billing access. The user who creates a workspace is automatically assigned the Owner role. Key characteristics of the Owner role: * Full access to all workspace settings and configuration * Can manage all users, including changing roles and removing members * Can add, configure, and remove products * Has access to billing and subscription management * Can manage groups and group memberships It is recommended to have at least one but no more than two Owners per workspace to maintain clear accountability while ensuring administrative continuity. ### Admin The Admin role has the same management capabilities as the Owner, with the exception of billing access. Admins are intended for day-to-day workspace management tasks. Key characteristics of the Admin role: * Full access to workspace settings * Can manage users, products, and groups * Cannot access billing or subscription management * Ideal for IT administrators or team leads who manage the workspace on behalf of the organization ### Member The Member role is the default role for regular workspace users. Members have limited visibility and no management capabilities at the workspace level. Key characteristics of the Member role: * Cannot access workspace settings, user management, or group management * Can access products they have been explicitly granted access to * Can view their own profile and switch between workspaces they belong to * Most workspace users should have the Member role ### Billing The Billing role is a specialized role for users who manage subscriptions and payments without needing general workspace administration access. Key characteristics of the Billing role: * Access to subscription and billing management for workspace products * Cannot manage workspace settings, users, or groups * Can access products they have been explicitly granted access to * Useful for finance or procurement team members ## Managing Workspace Users Workspace users are managed through the Users page, accessible from the workspace-level sidebar navigation. ### The Users List The Users page displays a table of all workspace members with the following columns:

Type	Description
Name	The user’s first name
Surname	The user’s last name
Email	The email address associated with the user’s Atomyx account
Status	The user’s status in the workspace (e.g. Active, Pending)
Role	The user’s workspace-level role (Owner, Admin, Member, Billing)

### Inviting Users The “+ Add user” button initiates the user invitation process. To invite a user to a workspace: 1. Enter the email address of the user to invite 2. Select the workspace role to assign (Owner, Admin, Member, or Billing) 3. Submit the invitation If the invited email address already has an Atomyx account, the user is added to the workspace immediately. If the email address does not have an existing account, an invitation is sent, and the user appears with a “Pending” status until they create their account and accept the invitation. {% hint style="info" %} **Note:** A user’s email address serves as their unique identifier across the Atomyx platform. Within a single workspace, each email address can only appear once. However, the same email can be a member of multiple workspaces. {% endhint %} ### Context Menu Actions Each user row in the table has a context menu (three-dot icon) with the following actions:

Action	Description
Change role	Opens a dialog to change the user’s workspace role
Remove	Removes the user from the workspace

Changing a user’s role takes effect immediately. The user’s product-level access is not affected by workspace role changes — product access is managed separately. ### User Status A workspace user can have one of the following statuses: * Active — the user has an Atomyx account and is an active member of the workspace * Pending — the user has been invited but has not yet created an account or accepted the invitation ## Groups Groups provide a way to organize workspace users into named collections. Groups are primarily used to simplify product-level access management by assigning product roles to groups rather than individual users. ### The Groups List The Groups page, accessible from the workspace-level sidebar navigation, displays a table with the following columns: | Type | Description | | ----------- | ----------------------------------------- | | Name | The display name of the group | | Description | A text description of the group’s purpose | | Users | The number of users in the group | ### Creating a Group The “+ Add group” button opens the group creation form. Creating a group requires: * Group name — a descriptive name for the group * Description — an optional description of the group’s purpose or membership criteria After creation, users can be added to the group. A user can be a member of multiple groups. ### Using Groups for Product Access Groups can be assigned to products with a product-level role. When a group is assigned to a product, all members of that group inherit the group’s product role. This simplifies access management when multiple users need the same level of access to a product. For example, creating a “Production Team” group and assigning it to an Atomyx Manage product with the Admin role means that any user added to the “Production Team” group automatically gains Admin access to that Atomyx Manage product. ## Product-Level Access In addition to workspace roles, users need explicit product-level access to use individual Atomyx products within a workspace. Being a member of a workspace does not automatically grant access to all products — access must be granted per product. ### Product Users Each product has a Users tab that displays the users who have been granted access to that specific product. The product users table shows:

Type	Description
Name	The user’s first name
Surname	The user’s last name
Email	The user’s email address
Status	The user’s status (Active, Pending)
Role	The user’s role within this specific product

Product-level roles are specific to each Atomyx product type. For example, Atomyx Manage defines an Admin role that grants full administrative access within that product. ### Product Groups Products also have a groups section showing workspace groups that have been granted access to the product. Each group entry shows: | Type | Description | | ----------- | -------------------------------------------- | | Name | The group name | | Description | The group description | | Users | The number of users in the group | | Role | The product-level role assigned to the group | When a group is assigned to a product, all members of that group gain access to the product with the specified role. This is the recommended approach for managing product access at scale. ### Access Hierarchy The access model follows a clear hierarchy: 1. A user must have an Atomyx account 2. The user must be a member of a workspace (with a workspace role) 3. The user must be granted access to specific products (either directly or through a group) 4. The user’s capabilities within the product are determined by their product-level role Each level is independent — a user’s workspace role does not determine their product role, and vice versa. A user could be a Member at the workspace level but an Admin within a specific product. ## Role Hierarchy Summary Atomyx Vault implements access control at three distinct levels. Understanding these levels is important for planning and implementing an access control strategy.

Level	Roles	Scope	Managed In
Platform	Super Admin	All workspaces, all products, all settings	Atomyx internal (not customer-accessible)
Workspace	Owner, Admin, Member, Billing	Workspace settings, users, groups, product management	Vault > Workspace > Users
Product	Product-specific (e.g. Admin)	Features and capabilities within a specific product	Vault > Workspace > Products > [Product] > Users

## Best Practices ### Role Assignment * Follow the principle of least privilege — assign the minimum role necessary for each user’s responsibilities * Use the Owner role sparingly, typically for one or two primary administrators * Use the Admin role for users who need to manage workspace resources but not billing * Assign the Billing role to finance team members who need subscription management access * Default to the Member role for most workspace users ### Group Management * Create groups based on functional roles or team structures (e.g. “Production Team”, “Design Team”, “Management”) * Use groups for product access rather than assigning individual users — this simplifies ongoing access management * Review group memberships when team composition changes * Document the purpose of each group in the description field ### User Lifecycle * Establish a process for onboarding new users: create account, invite to workspace, assign to groups, verify product access * When a user leaves the organization, remove them from all workspaces to revoke access * Periodically audit the users list to identify and remove inactive accounts * Monitor pending invitations and follow up with users who have not yet accepted ### Product Access * Grant product access only to users who actively need to use the product * Use groups to manage product access at scale rather than assigning individual users * Review product user lists periodically, especially after organizational changes * When removing a user from a workspace, verify that their product-level access is also revoked --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.atomyx.io/atomyx-vault/users-groups-and-roles.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.