Skip to main content
The Permissions workspace manages Permission groups—reusable collections of platform roles. A Permission group answers which kinds of operations may this principal perform. Resource Groups separately answer which restricted objects may it access.

​
Create a Permission group

Open Permissions, select Add, and configure: After saving, two sections become available:
  • Members assigns users and Service Accounts.
  • Roles adds or removes platform roles from the policy.
Changes affect current authorization. Test a representative principal after modifying a widely used Permission group.

​
Build roles by capability

Most product families expose read, write/run, and administrative levels. Do not use INSTANCE_ADMIN to solve an isolated access error. Determine whether the missing boundary is a platform role, Group membership, inactive identity, or disabled platform access.

​
Example policies

​
Automation operator

Can read automation definitions, run approved Jobs and Events, and inspect history, but cannot change templates or delete evidence.

​
Component author

Can read and edit Components and use Playground. Production activation can remain in a separate release-manager Permission group.

​
Finance workload

A Service Account receives only the execution roles it needs. A resource Group separately admits it to finance Tables and the settlement Storage folder.

​
Evaluate effective access

The Platform API and governed execution boundaries evaluate current state at request or execution time. UI visibility is only a convenience layer. Endpoint admission also supports human application users with platform access disabled: they still need ENDPOINT_INVOKE or INSTANCE_ADMIN. This admits the request, while operations inside its Component check the selected execution account’s roles and resource ACLs. In Caller mode that account is the invoking user; Service Account mode uses the saved executor. A Service Account requires platform access enabled in either mode. The Endpoint execution identity controls api.currentUser() for business logic and does not grant permissions.

​
Change and deletion safety

Before removing a role:
  1. List the Permission group’s members.
  2. Identify Jobs, Service Accounts, and operational teams that depend on it.
  3. Test the replacement policy with a non-production principal.
  4. Apply the change in a controlled window.
  5. Watch authorization failures, Job state, and Realtime disconnects.
Permission-group deletion is recoverable, but active principals can lose capability immediately. Restore does not guarantee that every external process automatically retries its failed operation.

​
Required administration roles

USER_READ, USER_WRITE, and USER_ADMIN can inspect Permission groups through the IAM hierarchy. INSTANCE_ADMIN is required to create, rename, edit, delete, restore, or change a Permission group’s role set. USER_ADMIN can assign or remove ordinary account members only for Permission groups they currently belong to. INSTANCE_ADMIN can assign any group. Service Account writers with management access can edit their workload’s Permission-group memberships, bounded by the writer’s own current memberships. An account with INSTANCE_ADMIN requires an instance administrator to mutate it. An account with USER_ADMIN requires a user administrator. These protections also apply when changing memberships; administration access does not remove the delegation ceiling.

​
Production checklist

  • Name policies after a job function or workload capability.
  • Prefer several small policies over one universal role bundle.
  • Keep INSTANCE_ADMIN rare and reviewed.
  • Separate execution from configuration administration.
  • Pair roles with Groups for restricted resources.
  • Test a real principal after policy changes.
  • Record owner and review cadence in description or metadata.
See Users, Service Accounts, and Groups.
Last modified on October 5, 2026