Scoped Permissions Setup Guide

How the permission model works

Zenmanage permissions are scoped at three levels. Access is inherited downward — a role granted at the account level applies everywhere unless overridden at a lower scope. A role granted only at the project level does not carry to other projects. A role granted only at the environment level does not carry to other environments in the same project.

Step 1 — Define account-level roles

Account-level roles control org-wide actions. These should be held only by the people who actively manage the account — typically platform leads, DevOps owners, or a small set of engineering managers.

1. 1. Navigate to Account Settings → Team & Permissions. This is the central access management view for your organization.
2. 2. Identify who needs account-level write access. Typically: the person who manages billing, creates or archives projects, and manages integrations. For most teams, this is one to three people.
3. 3. Set all other team members to account-level read access by default. Read access lets them see projects and environments without being able to modify account settings.
4. 4. Confirm that no role here grants automatic production write access to lower scopes. Project and environment permissions are set independently.

Step 2 — Assign project-level access

Project-level access controls who can see and modify flags within a given project. This is where you scope developers to the work they are actually responsible for.

1. 1. Open the project you want to configure. Go to Project Settings → Access.
2. 2. Add team members to the project with appropriate roles. A developer working on a feature in this project needs at minimum read access and typically write access across non-production environments.
3. 3. Use groups for teams that share the same access pattern. If three developers all need the same project-level access, assign them as a group rather than individually. This makes future access changes a single operation.
4. 4. Do not grant broad project-level write access as the default. Developers who only occasionally touch a project should be given read access until they have active work there.

Step 3 — Configure environment-level restrictions

Environment-level restrictions are the most important boundary for production safety. This is where you explicitly control who can act on production — separate from whatever project-level access they hold.

1. 1. Navigate to the project, then open the production environment settings. Each environment has its own access configuration.
2. 2. Set production to restricted. By default, environment access inherits from project access. Explicitly override this for production environments so that project write access does not automatically become production write access.
3. 3. Grant production write access only to the roles that actively manage production releases. This typically includes senior engineers, platform leads, and on-call owners — not all developers on the project.
4. 4. Confirm staging and development environments can remain open. Developers should be able to work freely in non-production environments. The goal is production protection, not slowing down development work.
5. 5. Repeat for every project that has a production environment. Environment restrictions are per-project — a setting on one project's production environment does not apply to others.

Step 4 — Restrict production-sensitive operations

Beyond environment-level access, specific operations on production carry higher risk than others. Zenmanage lets you restrict those individual operations to a named set of roles — so even a developer with production read access cannot trigger high-risk changes.

1. 1. Open Production Environment Settings → Restricted Operations.
2. 2. Enable restrictions on flag enable/disable and rollout changes as a baseline. These are the most common sources of unintended production impact.
3. 3. Enable restrictions on environment variable writes if your team uses Zenmanage to manage environment configuration.
4. 4. Assign the roles that are permitted to perform each restricted operation. Be specific — list named roles, not broad groups.

Common role patterns

These are starting-point role structures. Adjust to match your team's actual responsibilities and your organization's compliance requirements.