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.
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
Change and deletion safety
Before removing a role:- List the Permission group’s members.
- Identify Jobs, Service Accounts, and operational teams that depend on it.
- Test the replacement policy with a non-production principal.
- Apply the change in a controlled window.
- Watch authorization failures, Job state, and Realtime disconnects.
Required administration roles
The Permissions route is available to user administrators and writers according to the current user-management policy. Creating, editing, membership changes, role assignment, deletion, and restore are enforced again by the API.Production checklist
- Name policies after a job function or workload capability.
- Prefer several small policies over one universal role bundle.
- Keep
INSTANCE_ADMINrare 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.