Concepts
Roles, Grants, and Teams
Understand the permission model underneath Zenmanage's scopes — what a grant actually is, what each role can do, and how teams bundle access for a group of people.
A grant is a role attached to a scope
The Scoped Permissions Setup Guide already covers the three scope levels — account, project, environment — and how access inherits downward from a broader scope to a narrower one. This page covers the layer underneath that: what's actually being scoped.
Every permission in Zenmanage comes from a grant. A grant is a single record pairing a role with a scope — "editor at the project level," "viewer at the account level" — and attaching that pairing to a principal: either an individual user or a team. There's no permission that exists outside a grant. When you assign someone access in the UI, you're creating one of these records; when you review "who can do what," you're reading them back.
The four roles
A grant's role determines what its principal can do at that scope. There are four, and every grant uses exactly one of them:
Owner
Everything admin can do, plus the one thing admin can't: delete the account. Otherwise the two roles are identical.
Admin
Full control at its scope — flags, targets, segments, webhooks, billing, and managing other people's access — short of deleting the account.
Editor
Full CRUD on flags, targets, segments, and webhooks, including publishing and rolling back a target. No access to billing, user management, or team management.
Viewer
Read-only. Can see flags, targets, rules, and the audit trail at its scope, but can't change any of them.
Owner and admin being nearly interchangeable is deliberate — the distinction exists for exactly one irreversible action, not to create a hidden power tier. Most accounts only need one or two owners; day-to-day account and project administration is what admin is for.
Admin has a scope ceiling
Admin can be granted at the account or project level, but not at the environment level. The role includes account- and project-shaped actions — inviting users, managing teams, configuring billing — that don't make sense scoped to a single environment. If you want someone to have full control of just one environment, grant them editor there instead.
Teams are grants for a group
A grant's principal doesn't have to be a single user — it can be a team instead. A grant made to a team is inherited by every member of that team automatically: add someone to the team and they immediately pick up every grant the team holds; remove them and they lose those grants just as immediately. This is how you manage access for a group as one unit instead of replicating the same grants across each person by hand.
A user's actual access at any scope is the combination of their own direct grants and every grant held by every team they belong to — whichever role resolves to the broadest access wins. The two sources are kept visibly separate rather than flattened into one list: a user's own management page shows only their direct grants, explicitly excluding anything inherited from a team, and a team's page shows the grants that team confers on its members. To see the full picture for one person, check both places.
Effective role is computed server-side, every time
Nothing about a user's permissions is precomputed and stored. Every request that requires authorization walks that user's grants — direct and team-inherited — fresh, and derives what they're allowed to do from scratch. There's no separate "permissions" record that a grant change has to be synced into; the grants themselves are the only source of truth.
A change may need a reload to show up in an open session
The API re-evaluates permissions on every call, so a revoked or added grant takes effect immediately for anything that hits the server. The web app, however, fetches a user's effective role once when their session starts and holds onto it client-side for that session. If you change someone's access while they're actively using the app, they won't see the change reflected in the UI until they reload the page — that reload re-fetches their role from the server.
Where to go next
For step-by-step configuration of account, project, and environment access, see the Scoped Permissions Setup Guide. To roll this model out on an existing account, follow the Permissions & Audit Adoption Checklist. For how grant and team changes show up in the audit trail, see Data Retention and the Audit Trail. For the full feature overview, see the Permissions & Audit capability page.