Skip to main content

Roles

User roles define permissions and access levels within the platform.

Role Types

Admin

Full platform access and administrative capabilities

Permissions:

  • Manage all users, teams, and roles
  • View and modify all resources (apps, workflows, data sources)
  • Access platform infrastructure and Kubernetes resources
  • Configure billing and cost settings
  • Create and enforce governance policies
  • View audit logs and compliance reports
  • Manage integrations and settings

Use Cases:

  • Platform administrators
  • IT managers
  • DevOps leads
  • Security officers

Developer

Create and manage platform resources

Permissions:

  • Deploy and manage applications
  • Create and execute workflows
  • Manage workspaces and projects
  • Connect to data sources
  • Deploy and manage AI models
  • View cost and usage data
  • Access own namespace in Kubernetes

Restrictions:

  • Cannot manage other users
  • Cannot access billing settings
  • Cannot modify platform infrastructure
  • Cannot view other users' private resources

Use Cases:

  • Software engineers
  • DevOps engineers
  • Data scientists
  • ML engineers

App (Viewer)

Read-only access to applications and reports

Permissions:

  • View deployed applications
  • View workflow execution logs
  • Access dashboards and reports
  • View documentation
  • View own user profile

Restrictions:

  • Cannot create or modify any resources
  • Cannot deploy applications
  • Cannot execute workflows
  • Cannot access data sources
  • Cannot view cost data
  • Cannot access platform infrastructure

Use Cases:

  • Business stakeholders
  • Product managers
  • Auditors
  • Report consumers

Permission Matrix

FeatureAdminDeveloperViewer
View ApplicationsYesYesYes
Deploy ApplicationsYesYesNo
Modify ApplicationsYesOwn onlyNo
Delete ApplicationsYesOwn onlyNo
Create WorkflowsYesYesNo
Execute WorkflowsYesYesNo
View Workflow LogsYesYesYes (shared)
Manage Data SourcesYesYesNo
Create ProjectsYesYesNo
Manage WorkspacesYesYes (own)No
Deploy ModelsYesYesNo
View FinOpsYesYesNo
Manage BillingYesNoNo
Manage UsersYesNoNo
Create TeamsYesNoNo
Governance PoliciesYesView onlyNo
Platform AccessYesLimitedNo
Audit LogsYesOwn onlyNo

Role Assignment

Assigning Roles to Users

During User Invitation:

  1. Click Invite User
  2. Select role from dropdown
  3. Send invitation

For Existing Users:

  1. Go to SettingsUsers
  2. Click user name
  3. Select new role
  4. Click Update Role

Role Changes

  • Role changes take effect immediately
  • User must re-login for some permissions
  • Previous access is revoked automatically
  • Resources owned by user are not affected

Custom Roles (Enterprise Feature)

Create custom roles with specific permissions:

Creating Custom Role

  1. Go to SettingsRoles
  2. Click Create Custom Role
  3. Enter role name and description
  4. Select permissions from categories:
    • Applications
    • Workflows
    • Data Sources
    • Projects & Workspaces
    • Models
    • Governance
    • Platform
    • Users & Teams
  5. Save custom role

Permission Granularity

Customize permissions at detailed level:

  • View: Read-only access
  • Create: Can create new resources
  • Update: Can modify existing resources
  • Delete: Can remove resources
  • Execute: Can run workflows/apps
  • Share: Can share with other users

Best Practices

Role Assignment Guidelines

  • Principle of Least Privilege: Give users minimum permissions needed
  • Regular Reviews: Audit user roles quarterly
  • Temporary Elevated Access: Use time-limited admin access for temporary needs
  • Separation of Duties: Don't give all permissions to one person

Admin Role

  • Limit number of admin users
  • Require MFA for all admins
  • Document why each user needs admin access
  • Review admin list monthly

Developer Role

  • Default role for technical team members
  • Provides balance of access and security
  • Can work independently without admin intervention
  • Resources are isolated between developers

Viewer Role

  • Default role for non-technical stakeholders
  • Provides visibility without risk of changes
  • Useful for compliance and audit requirements
  • Can be expanded to specific apps/dashboards

Role-Based Access Control (RBAC)

How RBAC Works

  1. User authenticates and logs in
  2. System retrieves user's role(s)
  3. Each request checks user's permissions
  4. Allow or deny based on role permissions
  5. Audit log records access attempts

Resource Ownership

  • Users can always access resources they created
  • Ownership can be transferred to another user
  • Team resources are accessible to all team members
  • Admins can access all resources

Namespace Isolation

For platform/Kubernetes access:

  • Each developer gets own namespace
  • Developers can only access own namespace
  • Admins can access all namespaces
  • Service accounts tied to user roles
tip

Start new users as Viewer, upgrade to Developer as they get comfortable, only grant Admin when absolutely necessary.