Control access with predefined roles

Automation orchestrator ships with seven built-in roles — four at system scope and three at project scope. Each role is a named bundle of built-in policies. Create custom roles through the Access Management > Roles tab or through the API.

Roles are not a separate authorization layer. Each role is a named bundle of built-in policies. Each role references one or more built-in policies. Assigning a role to a group or user means applying those policies to the assignee.

  • Built-in roles provide a familiar experience for administrators who expect role-based assignment.
  • Built-in policies can express conditions that traditional roles cannot.
  • You can create custom roles by combining built-in policies.
  • Roles can be scoped to the system level or to a specific project.

Create custom roles through Access Management > Roles or through the API.

System-scope roles

Admin

Full access to all resources and operations.

  • Full CRUD access to all resource types (workflows, credentials, projects, groups, users, integrations, tools, LLM models, service accounts)
  • Can assign and revoke roles for users and groups (role-assignment:assign, role-assignment:revoke)
  • Can create, update, and delete roles
  • Can configure identity providers (identity-provider:create, read, update, delete, test)
  • Can access authorization query endpoints (authz:query)
  • Can manage group membership (group:manage-members)
  • Can manage approvals (approval:create, read, decide)
  • Can manage invocations (invocation:create, read, cancel)
  • Can upload and download files (files:upload, files:download)
  • Can execute administrative token revocation (admin:revocation:read, execute)
  • Can read and write runtime settings (setting:read, write)

Typical assignments: platform administrators, DevOps leads, security administrators.

Note:

The built-in administrator account has the admin role, which includes allow policies for every resource type and action. It goes through the same policy evaluation as all other users.

Auditor

Read-only access to resources with audit log visibility.

  • Read access to workflows, executions, credentials, groups, users, and projects
  • Read access to roles, policies, and own role assignments
  • Read access to approvals
  • Read access to integrations, tools, and LLM model configurations
  • Read access to service accounts and administrative revocation events
  • Read access to identity providers
  • Read-only access to runtime settings
  • Lightweight user and group directory lookups
  • Cannot create, update, or delete any resources (including credentials)
  • Cannot run executions
  • Cannot manage role assignments or group membership

Typical assignments: compliance auditors, security analysts, stakeholders reviewing workflows, support staff troubleshooting issues.

User

Standard user with project creation and platform-level read access. Workflow, credential, and execution access requires a project-scoped role assignment.

  • Create projects (project:create)
  • Upload and download files (files:upload, files:download)
  • Read access to integrations, tools, and LLM model configurations (integration:read, tool:read, llm_model:read)
  • Lightweight user and group directory lookups (user-directory:read, group-directory:read)
  • Cannot create, read, update, or delete workflows, credentials, or executions at system scope
  • Cannot manage groups or role assignments
  • Cannot configure identity providers
  • Cannot create or modify roles

To grant workflow and credential access, assign a project-scoped role such as project-user or project-admin.

Typical assignments: platform users who need to create projects and receive project-scoped roles for workflow access.

Project-scope roles

Project-scope roles provide the same permission model scoped to a specific project. Resources outside the assigned project are not accessible through these roles.

Project-admin

Full access to a project and its resources, including role management.

  • Full CRUD access to workflows, executions, and credentials within the project
  • Can assign and revoke project-scoped roles (role-assignment:assign, role-assignment:revoke)
  • Can create, read, update, and delete roles within the project
  • Can read policies within the project
  • Can manage approvals within the project
  • Can manage service accounts within the project
  • Can upload and download files within the project
  • Read access to integrations within the project

Typical assignments: project leads, team leads responsible for a specific automation domain.

Project-user

Standard access within a project.

  • Create, read, update, and delete workflows within the project
  • Create, read, and update credentials within the project (cannot delete)
  • Read and run executions within the project
  • Read and decide approvals within the project (approval:read, approval:decide)
  • Read access to roles and policies within the project
  • Read access to integrations within the project
  • Can upload and download files within the project
  • Cannot manage role assignments or group membership

Typical assignments: workflow developers working within a specific project.

Project-auditor

Read-only access within a project.

  • Read access to workflows, executions, credentials, and approvals within the project
  • Read access to roles, policies, and service accounts within the project
  • Read access to integrations within the project
  • Can download files within the project
  • Cannot create, update, delete, or run any resources (including credentials)

Typical assignments: auditors reviewing automation within a specific project or team.

Authenticated role and baseline authorization

After a user logs in, automation orchestrator places them in the authenticated group and assigns the authenticated role. This role provides baseline authorization so that deny-by-default does not block common self-service operations:

  • Read and update own user profile (user:read:self, user:update:self)
  • View own role assignments (role-assignment:read:self)
  • View and detach own identity provider links (user_identity:read:self, user_identity:detach:self)

The authenticated role is a built-in role. The authenticated group is visible across all areas of the interface.

The authenticated role does not control login access. For identity provider users, login requires either Allow all authenticated enabled on the provider or explicit group mappings that match the user's identity provider groups. Without either, the user cannot log in and never reaches the authenticated group.

Approval authority

Automation orchestrator does not include a dedicated approver role. The approval:decide permission grants approval authority. The following built-in roles include this permission:

  • Admin at system scope
  • Project-admin and Project-user at project scope

If you have one of these roles, you can approve or reject human-in-the-loop approval nodes in workflows you can access.

To restrict approval authority to specific users, create a custom role that includes the built-in approval:decide:project policy and assign it to the relevant group or users.

Custom roles

View and manage roles under Access Management > Roles tab.

The table displays roles with columns: Name, Description, Scope (System or Project), Project (the associated project, if project-scoped), and Type (Built-in or Custom). Each row expands to show the policies included in that role. Built-in roles show a grey "Built-in" label and cannot be edited or deleted. Custom roles show a "Custom" label.

You can create custom roles by combining built-in policies. Navigate to Access Management > Roles and select Create role. You need the admin role or the role:create permission.