Roles
The platform uses a role-based access control (RBAC) system. Five roles are defined at startup, and each role determines which navigation items and features a user can access.
The Five Roles
The platform creates these roles on server startup:
admin, developer, app, user, platform-admin
New users are assigned the app role by default when created by an admin or during self-registration.
Admin
Full platform access plus administrative capabilities.
The Admin menu includes everything in the Developer menu, plus an ADMIN section:
MAIN Section:
- Dashboard
- Apps
- Add-ons
- Data Sources
- Workflows (Builder, Monitor, Nodes, Tools)
- Projects
- AI Gateway (Models, Fine-tuning, Analytics, Guardrails, Prompts)
- MLOps (Workbench, Model Registry, AutoML, Experiments)
- Governance (Manager, Solutions, Policies, Snapshots, Compliance, Audit Log)
- Marketplace
OPERATIONS Section:
- Environments
- Platform
ADMIN Section (admin-only):
- Users -- create, edit, archive, assign roles, reset passwords
- FinOps (Dashboard, Resource Groups, Budgets, Schedules, Cost Explorer, Executions)
- MFA Settings -- enable/enforce MFA, configure grace periods and allowed methods
SUPPORT Section:
- STAN (AI assistant)
- Contact
Administrative Permissions:
- Manage all users: create accounts, assign roles, archive/unarchive, reset passwords
- Toggle admin and developer roles for any user (except own admin status)
- View all users list and user details
- Configure MFA enforcement settings (enable, enforce, set grace period)
- Check and unlock locked accounts
- Access all FinOps features: budgets, schedules, cost explorer, resource groups
- Full access to governance policies, audit logs, and compliance reports
Developer
Full application functionality without admin features.
The Developer menu includes all sections from the Admin menu except the ADMIN section:
MAIN Section:
- Dashboard
- Apps
- Add-ons
- Data Sources
- Workflows (Builder, Monitor, Nodes, Tools)
- Projects
- AI Gateway (Models, Fine-tuning, Analytics, Guardrails, Prompts)
- MLOps (Workbench, Model Registry, AutoML, Experiments)
- Governance (Manager, Solutions, Policies, Snapshots, Compliance, Audit Log)
- Marketplace
OPERATIONS Section:
- Environments
- Platform
SUPPORT Section:
- STAN (AI assistant)
- Contact
Developer Restrictions:
- Cannot access the Users management page
- Cannot access FinOps administration
- Cannot configure MFA settings for the platform
- Cannot assign or remove roles from other users
App (Default Role)
Dashboard access only -- the most restricted role.
The App menu contains only:
MAIN Section:
- Dashboard
This is the default role assigned to all new users. Users with only the app role see a minimal sidebar and can access the dashboard. To access other features, an admin must upgrade the user to the developer or admin role.
User
Basic access role (legacy).
The user role exists in the system for backward compatibility. In the current role hierarchy:
- If a user has the
userrole but notdeveloperoradmin, they receive the same App/User menu (Dashboard only) - The
getRoleBasedMenufunction checks roles in priority order: admin > developer > user/app
Platform Admin
Infrastructure-level administration.
The platform-admin role is automatically assigned to the admin user in development mode. It provides platform-level administrative capabilities beyond the standard admin role.
Role Priority and Menu Resolution
The system determines which menu to display using this priority:
- If the user has the admin role: show the full Admin menu
- If the user has the developer role: show the Developer menu
- Otherwise: show the basic User/App menu (Dashboard only)
A user can hold multiple roles simultaneously. The highest-priority role determines the menu.
Permission Matrix
| Feature | Admin | Developer | App/User |
|---|---|---|---|
| Dashboard | Yes | Yes | Yes |
| Apps (deploy, manage) | Yes | Yes | No |
| Add-ons | Yes | Yes | No |
| Data Sources | Yes | Yes | No |
| Workflow Builder | Yes | Yes | No |
| Workflow Monitor | Yes | Yes | No |
| Workflow Nodes | Yes | Yes | No |
| Workflow Tools | Yes | Yes | No |
| Projects | Yes | Yes | No |
| AI Gateway (Models) | Yes | Yes | No |
| AI Gateway (Fine-tuning) | Yes | Yes | No |
| AI Gateway (Analytics) | Yes | Yes | No |
| AI Gateway (Guardrails) | Yes | Yes | No |
| AI Gateway (Prompts) | Yes | Yes | No |
| MLOps (Workbench) | Yes | Yes | No |
| MLOps (Model Registry) | Yes | Yes | No |
| MLOps (AutoML) | Yes | Yes | No |
| MLOps (Experiments) | Yes | Yes | No |
| Governance (all sub-pages) | Yes | Yes | No |
| Marketplace | Yes | Yes | No |
| Environments | Yes | Yes | No |
| Platform | Yes | Yes | No |
| STAN | Yes | Yes | No |
| Contact | Yes | Yes | No |
| Admin: Users | Yes | No | No |
| Admin: FinOps | Yes | No | No |
| Admin: MFA Settings | Yes | No | No |
How Roles Are Assigned
During User Creation
When an admin creates a user via the Users page:
- The user account is created with a temporary password
- The default app role is assigned automatically with
scope: null(global scope) - The admin can then toggle the developer or admin roles
Changing Roles
Toggle Admin Role (admin only):
- Admins can grant or revoke the admin role for any user
- An admin cannot modify their own admin status (self-protection)
- Changes take effect immediately
Toggle Developer Role (admin only):
- Admins can grant or revoke the developer role for any user
- Changes take effect immediately
Assign Role (admin only):
- The
users.assignRolemethod accepts roles:admin,developer,user - Roles are added with
scope: nullfor global access
Role Changes and Sessions
- Role changes take effect on the server immediately
- The user's sidebar menu updates on their next page load or login
- Existing resources owned by the user are not affected by role changes
- Archived users have all login tokens cleared, forcing immediate logout
Multi-Tenant Role Considerations
In multi-tenant (SaaS) mode, roles work alongside organization membership:
- Users belong to organizations and have an organization role (owner, admin, member) separate from their platform role
- Resource access is filtered by organization: users can only see resources belonging to their organization
- The
users.shareablepublication only returns users within the same organization - Solo users (single-person organizations) cannot share resources with others
In single-tenant mode, all users can see and share with all other users.
Best Practices
Role Assignment Guidelines
- Start with App role: New users receive the app role by default. Upgrade as needed.
- Principle of Least Privilege: Only grant developer or admin roles when the user's responsibilities require it.
- Limit admin accounts: Keep the number of admin users small. Document why each user needs admin access.
- Require MFA for admins: Use MFA enforcement to ensure all admin accounts have MFA enabled.
Regular Access Reviews
- Review user roles quarterly
- Check for users with admin access who no longer need it
- Identify inactive users for archiving
- Verify that archived users cannot log in
Self-Protection
The platform prevents certain dangerous operations:
- Admins cannot remove their own admin role
- Admins cannot archive themselves
- Admin role verification is performed on every protected action
When onboarding a new team member, create their account with the default app role, then upgrade to developer once they are familiar with the platform. Only grant admin access when absolutely necessary.