Skip to main content

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 user role but not developer or admin, they receive the same App/User menu (Dashboard only)
  • The getRoleBasedMenu function 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:

  1. If the user has the admin role: show the full Admin menu
  2. If the user has the developer role: show the Developer menu
  3. 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

FeatureAdminDeveloperApp/User
DashboardYesYesYes
Apps (deploy, manage)YesYesNo
Add-onsYesYesNo
Data SourcesYesYesNo
Workflow BuilderYesYesNo
Workflow MonitorYesYesNo
Workflow NodesYesYesNo
Workflow ToolsYesYesNo
ProjectsYesYesNo
AI Gateway (Models)YesYesNo
AI Gateway (Fine-tuning)YesYesNo
AI Gateway (Analytics)YesYesNo
AI Gateway (Guardrails)YesYesNo
AI Gateway (Prompts)YesYesNo
MLOps (Workbench)YesYesNo
MLOps (Model Registry)YesYesNo
MLOps (AutoML)YesYesNo
MLOps (Experiments)YesYesNo
Governance (all sub-pages)YesYesNo
MarketplaceYesYesNo
EnvironmentsYesYesNo
PlatformYesYesNo
STANYesYesNo
ContactYesYesNo
Admin: UsersYesNoNo
Admin: FinOpsYesNoNo
Admin: MFA SettingsYesNoNo

How Roles Are Assigned

During User Creation

When an admin creates a user via the Users page:

  1. The user account is created with a temporary password
  2. The default app role is assigned automatically with scope: null (global scope)
  3. 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.assignRole method accepts roles: admin, developer, user
  • Roles are added with scope: null for 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.shareable publication 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
tip

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.