Skip to main content

​
Overview

Every user has one organization role: owner, admin, editor, or viewer. Teams restrict which projects editors and viewers can see; they do not create a second role. An unassigned project is organization-wide.

​
Role permissions

Owners are the SSO break-glass role and remain exempt from enforcement. A role grants capability, while project/team scope decides where that capability applies.

​
Role precedence

Roles form a capability hierarchy: owner includes admin capabilities, admin includes editor capabilities, and editor includes viewer capabilities. A membership has exactly one role, so changing it replaces the previous role; roles are not merged across teams. Team membership can add project visibility but never elevates the organization role. Credential scopes and project/environment bindings can only narrow the principal’s authority.

​
Teams and project scope

Admins and owners see every project and can assign teams. Editors and viewers see projects with no team assignment plus projects assigned to one of their teams. Assigning multiple teams is additive. Direct member exceptions and team- or project-specific roles are not supported.

​
Credentials and precedence

Authorization never combines credentials. A session, management key, service-account token, or SDK key is evaluated as its own principal.
  • Management keys are bound to one organization, project, and environment. They support compatible project workflows but cannot administer organization-wide keys, billing, members, teams, SSO, service accounts, audit, or snapshot-wide reads.
  • Service-account tokens use only their declared scopes and optional project/environment bindings. Token scopes must be a subset of the creator’s role at creation time.
  • SDK keys access the data plane only. Client and server keys currently receive the same snapshot, including targeting rules; reduced client snapshots are planned. Never ship a server key to a browser or mobile app. See SDK keys, management API keys, and service account tokens.
  • Environment and project bindings narrow authority. They never add permission or team membership.

​
Production safeguards

Production state changes require flag.production.toggle (admin or owner). Definition changes also require that permission when the project has a production environment because they affect every environment. Flag creation requires flag.create and does not require the production permission. Matching approval policies queue environment changes for review; they do not grant missing RBAC permission. Conflict checks still apply after approval. Related: Create a service account · Review production changes · Approval workflows.