Roles

The platform uses a role-based access control (RBAC) system. There are three roles -- admin, developer, and app -- and every user has exactly one. The role determines which navigation items and features the user can access. Admins can additionally grant reviewer privileges to any user, which adds the Governance review pages to their menu.

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:

• Home, Dashboard
• Apps, Add-ons, Data Sources, Projects
• Governance (Solutions, Policies, Reviews)
• Marketplace

AI Section:

• Library (Prompts, Skills, Imprints, Artifacts)
• Agents (Overview, Sessions, Playground, Primitives, Avatars)
• Workflows (Builder, Monitor, Nodes, Tools)
• AI Gateway (Models, Routers, Fine-tuning, Analytics, Guardrails, Data Forge)
• MLOps (Workbench, Model Registry, AutoML, Experiments)

OPERATIONS Section:

• Environments
• Platform

ADMIN Section (admin-only):

• Users -- create, edit, archive, assign roles, reset passwords
• FinOps (Dashboard, Cost Explorer, Budgets, Schedules, Executions)
• Compute -- compute governance for instance categories

SUPPORT Section:

• 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 is identical to the Admin menu minus the ADMIN section.

Developer Restrictions:

• Cannot access the Users management page
• Cannot access FinOps administration
• Cannot access Compute governance
• Cannot assign or remove roles from other users

App (Default Role)

A locked, simplified end-user experience.

App users see a minimal sidebar with My Apps -- the grid of applications that have been shared with them. They open and use those apps; they do not see the builder, AI, or operations features. This is the default role for all new users and is intended for business end-users. To access other features, an admin must upgrade the user to the developer or admin role.

Reviewer Privileges

Reviewer is not a separate role but a privilege an admin can grant to a user from the Users page. A user with reviewer privileges gets Home, Dashboard, and the Governance review pages (Solutions, Policies, Reviews) so they can participate in review workflows without full developer access.

Role Priority and Menu Resolution

The system determines which menu to display using this priority: admin, then developer, then reviewer privileges, then app. The highest-priority match determines the menu.

Permission Matrix

Feature	Admin	Developer	App
Dashboard	Yes	Yes	No
My Apps (use shared apps)	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 (Routers, Data Forge)	Yes	Yes	No
Library (Prompts, Skills, Imprints, Artifacts)	Yes	Yes	No
Agents	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 (Solutions, Policies, Reviews)	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: Compute	Yes	No	No

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

Toggle Reviewer Privileges (admin only):

• Admins can grant or revoke reviewer privileges for any user
• Changes take effect immediately

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.