Overview
User management in Oumi is handled from a centralized location within the UI, making it easy to manage access and roles across your organization. To access user settings:- Click your profile icon in the top navigation bar.
- Select Organization Settings from the dropdown menu.
- View the list of organization members and update roles as needed.
Oumi roles
Roles define what actions a user can take at both the organization and project levels. By combining organization-level and project-level roles, you can control access broadly across your workspace while still managing more granular permissions within individual projects.Organization roles
- Owner - the top-level role with complete authority, including managing settings, users, and billing. Each organization has a single designated owner role.
- Admins - have broad management capabilities, such as inviting users and configuring organization settings, but cannot delete the organization or manage payment methods.
- Members - limited to viewing and working within projects they’ve created or been added to.
| Role | Description |
|---|---|
| Owner | Full control over the organization (one per org) |
| Admin | Full management rights; cannot delete the org or manage payment methods |
| Member | Standard access; can only view and use projects they are explicitly added to |
Project roles
Project roles define what a user can do within a specific project.- Project Admin - has full control, including managing members, updating settings, and deleting the project.
- Editor - can actively contribute by creating and modifying resources such as datasets, models, and evaluations.
- Viewer - has read-only access and can explore project resources without making changes.
| Role | Description |
|---|---|
| Admin | Full control over the project (manage members, edit settings, delete project) |
| Editor | Create and modify resources (datasets, models, evaluations, etc.) |
| Viewer | Read-only access to all project resources |
How roles interact
Organization and project roles work together to determine a user’s effective access level. Organization owners and admins automatically have full access to every project in the organization, and do not need to be assigned separate project roles. In contrast, organization members do not have access to any projects by default, and must be explicitly added to each project with an assigned role. Roles follow a clear hierarchy within a project: Admin > Editor > Viewer. Higher-level roles inherit the permissions of the roles below them, meaning an Admin can perform all actions available to editors and viewers, and an Editor can perform all actions available to viewers.Role assignment & access control
A user must belong to an organization before they can be assigned any role within its projects. If a user is removed from the organization, they immediately lose access to all associated projects. Each organization is limited to a single owner. This role cannot be removed directly; ownership must be transferred to another user if a change is needed. Organization owners and admins have visibility into all projects by default, while members can only see and access the projects they have been explicitly added to.Organization access & permissions
The following matrix shows what actions owners, admins, and members can perform within an organization.| Action | Owner | Admin | Member |
|---|---|---|---|
| View org details | yes | yes | yes |
| Update org settings | yes | yes | no |
| Delete org | yes | no | no |
| Invite users to org | yes | yes | no |
| Remove users from org | yes | yes | no |
| Update user roles in org | yes | yes | no |
| Cancel pending invitations | yes | yes | no |
| View org member list | yes | yes | yes |
| View pending invitations | yes | yes | yes |
| Manage org-level API keys (LLM providers) | yes | yes | no |
| View org-level API keys | yes | yes | yes |
| Access billing portal | yes | yes | no |
| View payment methods | yes | yes | no |
| Update/delete payment methods | yes | no | no |
| View org stats | yes | yes | yes |
| Create projects | yes | yes | yes |
| List projects (accessible only) | yes | yes | yes |
Project permissions
The following matrix defines what each role can do within a project, from managing settings and members to creating and using resources.| Action | Org Owner/Admin | Project Admin | Project Editor | Project Viewer |
|---|---|---|---|---|
| View project | yes | yes | yes | yes |
| Update project settings | yes | yes | no | no |
| Delete project | yes | yes | no | no |
| Add/remove project members | yes | yes | no | no |
| Update project member roles | yes | yes | no | no |
| Manage project API keys (LLM providers) | yes | yes | yes | no |
| View project API keys | yes | yes | yes | yes |
| Create resources (datasets, models, experiments, evaluators, recipes, tags) | yes | yes | yes | no |
| Edit/delete resources | yes | yes | yes | no |
| Run operations (training, evaluation, analysis, synthesis) | yes | yes | yes | no |
| Stop running operations | yes | yes | yes | no |
| View resources and results | yes | yes | yes | yes |
| Download datasets and models | yes | yes | yes | yes |
| Upload datasources | yes | yes | yes | no |
| Use agent chat | yes | yes | yes | no |
| Preview synthesis/evaluators | yes | yes | yes | yes |