Three roles, clearly separated
Every member receives a role inside the organization. Assign the lowest level that lets them do their job; access can be raised later without sharing credentials or creating a separate flag workspace.
Runs the account
Manages members, roles, billing, approvals, credentials, webhooks, streaming keys, kill switches, and other organization-wide administration.
Best for account owners, platform leads, and trusted operations staff.
Manages flags
Creates and edits flags, targeting rules, variants, rollouts, dependencies, notes, groups, and environment configurations. Editors can archive flags, but permanent deletion remains admin-only.
No billing, member management, approvals, credential issuance, kill-switch control, or webhook and streaming-key administration.
Keeps everyone informed
Views the organization dashboard, flags, configurations, audit information, and evaluation results without changing live behavior.
Best for project managers, executives, support teams, and stakeholders who need a reliable overall view.
The Viewer role uses viewer in application API role values. Management API keys separately use the key scope management-reader.
What each role can manage
| Capability | Viewer | Editor | Admin |
|---|---|---|---|
| View dashboard, flags & organization data | Yes | Yes | Yes |
| Flags | |||
Create flags flags.create | Grant | Yes | Yes |
Edit and toggle flags, targeting, variants & rollout flags.edit | Grant | Yes | Yes |
Permanently delete flags flags.delete | Grant | Grant | Yes |
Manage flag groups flags.manage_groups | Grant | Yes | Yes |
Manage reusable flag templates flags.manage_templates | Grant | Grant | Yes |
Manage user groups & per-flag security flags.security | Grant | Grant | Yes |
| Automation & rollout safety | |||
View flag automation automation.view | Grant | Yes | Yes |
Create, edit, run, suspend & delete automation automation.manage | Grant | Yes | Yes |
View approval requests approvals.view | Grant | Grant | Yes |
Approve or reject protected changes approvals.decide | Grant | Grant | Yes |
View kill-switch status killswitch.view | Grant | Grant | Yes |
Engage or clear the kill switch killswitch.manage | Grant | Grant | Yes |
| Insights | |||
View flag analytics analytics.view | Grant | Yes | Yes |
View evaluation performance performance.view | Grant | Yes | Yes |
View change log changelog.view | Grant | Yes | Yes |
View client integration error logs errorlogs.view | Grant | Yes | Yes |
| Configuration | |||
Add, rename, disable & remove environments manage_environments | Grant | Yes | Yes |
Add, rename & remove applications manage_applications | Grant | Yes | Yes |
View cache state cache.view | Grant | Yes | Yes |
Purge evaluation cache cache.purge | Grant | Yes | Yes |
| Developer tools | |||
Use Feature, HTTP & GraphQL testers tester.use | Grant | Yes | Yes |
View SDK setup sdk.view | Grant | Yes | Yes |
View API reference apidocs.view | Grant | Yes | Yes |
| Integrations & keys | |||
Manage webhooks webhooks.manage | Grant | Grant | Yes |
Create, rotate & revoke management keys managementkeys.manage | Grant | Grant | Yes |
Create, rotate & revoke streaming keys streaming.manage | Grant | Grant | Yes |
| People & account | |||
View and manage eligible users users.view | Grant | Yes | Yes |
View subscription & billing billing.view | Grant | Grant | Yes |
Custom Access can also remove a normally included Editor capability. Admin access is fixed and is never narrowed by a custom level.
Automation follows the same split as other protected changes: Editors and Admins can create, validate, and manage a plan's lifecycle; approval decisions default to Admin. Viewers can see organization planned events, while opening a flag’s Automation workspace requires automation.view. See Flag automation for the full guide.
Build a role around the job
Admins can create named access levels from Settings → Custom Access, choose a Viewer or Editor base, and make the checked capability list the member’s complete effective access. This supports both elevation and restriction without inventing another global role.
Grant above the base role
Give a Viewer selected delivery tools, or give an Editor a normally admin-only action such as approvals, flag deletion, per-flag security, webhooks, or key management.
Take access away
Unticking a capability the base role normally owns removes its navigation item, blocks direct route access, and is enforced again by the server endpoint.
Assign once, update everyone
Assign a named level from Settings → Users. Editing the level changes every assigned member on their next request; the expanded level shows exactly who is affected.
Draft, enable, or suspend
Levels have names, descriptions, base roles, grouped select-all controls, and an on/off switch. Turning one off keeps assignments but returns members to plain base-role access until it is enabled again.
Resource-level access works alongside capabilities
The flags.security capability opens Settings → User Groups and each flag’s Security tab. Assigning groups to a flag hides that flag from everyone outside those groups, while administrators retain access. Authorized group members see the restricted flag throughout the UI and tester dropdowns; unauthorized users cannot discover it through lists or direct routes.
How organization flags stay protected
A role is only one part of the decision. Every request is authenticated, tied to an organization, checked against the requested action, and then checked again against the resource being accessed.
Authenticated membership
The signed session identifies the member, their effective organization role, and the organization they are working in.
Organization isolation
Data queries are scoped by organization. Ownership checks also prevent a flag or configuration identifier from reaching another organization’s records.
Action-level enforcement
The server enforces role rules on every protected endpoint. Hiding a button in the interface is a convenience, never the security boundary.
Approvals and audit history
Protected environments can require admin approval for editor changes, while audit records preserve who changed what and when.
Match access to responsibility
Keep account, billing, credentials, and production safety controls with a small trusted group.
Give engineers and product operators the tools to ship without opening administration access.
Let leadership and project teams follow status and outcomes without risking an accidental change.
Human access and machine access stay separate
Dashboard members use authenticated sessions. Applications and automation use purpose-built keys with narrower scopes, so a service receives only the access it needs.
Management keys
Admins issue keys with explicit evaluate, read, or write permissions and can restrict them to specific applications and environments.
Streaming keys
Admins issue keys pinned to a flag and environment for real-time updates. They do not grant access to management endpoints.
Key secrets are shown once when created or rotated and are not stored in a form that can be displayed later.