Manage access to environments
Environments access levels
Under Access to environments, you can choose one of the following options:
Manage and use all environments - Grants full access to all environments within the space. The user can manage all content and tags, depending on the role’s assigned permissions.
Select environments or aliases to give access - Allows you to select specific environments and configure granular permissions for each. For example, you can give read-only access in Production and full edit rights in Development.
Master environment only (default) - Allows you to set your role to access only the master environment. The role won't be able to access non-master environments.
Selected environments - Allows you to select one or multiple specific environments your role will be able to access.
Manage and use all environments - Allows you to set a role to access all environments in a space.
NOTE: With the “Manage and use all environments” permission, the role’s access to master environment content is defined by its content and media permissions. In sandbox environments, this role has full access to all content.
NOTE: A space Administrator role has full access to all environments (including the master environment) and their content.
How to configure access to environments
To configure a role's access to environments:
Go to the Environments tab in the Role editor page.
Under the Access to environments area, select the required environments' access level. If you selected the Selected environments option, please continue to step 3 in How to configure access to a selected environment.
Optional: Under the Manage entities in master/ Manage entities in selected environments area, select the slider(s) to enable the user to create, edit and delete content types and/ or tags.
Optional (only for Manage and use all environments option): Under the Manage environments area, select the slider to enable the user to create environment aliases and change their target environment.
Click Save changes to save the role.

How to configure access to a selected environment
To configure a role's access to a selected environment:
Go to the Environments tab in the Role editor page.
Under the Access to environments area, select the Selected environments option.
Under the Allowed environments area, select the environment you would like your role to be able to access. The environment is added to the Allowed environments list.
Optional: Repeat step 3 to add another environment to the Allowed environments list.
Optional: To remove an environment from the Allowed environments list, click the X button against this environment.
Finish setting environments permissions starting from step 3 in How to configure access to environments.

Assigning multiple environment access options to a single user
When multiple roles are assigned to a single user, the environment access options and related content policies for those roles will be merged. Different environment access options defined in these roles override or combine each other according to the following principles:
“Manage and use all environments” option overrides the “Selected environments” option.
NOTE: The “Manage and use all environments” option is equivalent to setting the Environment permission to “all”. You can read more about this override here. If it is set in any of the roles assigned to a user, this user can access all environments, and any content- or media-related Allow or Deny rule only applies to the master environment. Other environments are fully accessible without restrictions.
“Selected environments” option overrides the “Master environment only” option.
NOTE: The “Selected environments” option needs to explicitly define all environments that a user is allowed to access. A user doesn’t have access to the master environment unless the master environment is added as one of “Allowed environments”.
“Selected environments” options combine to cover all “Allowed environments” across roles.
NOTE: All content- or media-related Allow and Deny rules defined in either of the roles are combined and apply to all environments selected for access in those roles. This means that the user has the same content and media restrictions in all selected environments, regardless of which role those rules were defined in.
The table and comments below explain how an example combination of roles with different environment permissions assigned to the same user affects the user’s access to environments.
You can configure a role’s access to specific environments under the Environments tab in the Role editor. With granular environment permissions enabled for your organization, you can define different access levels per environment, giving administrators more precise control.
This feature allows you to:
Grant read-only or read/write permissions to content types and tags per environment.
Protect production environments while allowing more flexible access in staging or development.
Prevent accidental edits to live content by limiting create/edit/delete actions.
When granular environment permissions are activated, the Access to environments section displays detailed permission options for each environment, as shown below:
Environment / Alias | Content types (Read / Create/Edit / Delete) | Tags (Read / Create/Edit / Delete) |
Master | Read only | Read only |
Staging | Read / Create/Edit | Read |
Development | Read / Create/Edit / Delete | Read / Create/Edit / Delete |
(Admins can adjust these per environment as needed.)
NOTE: To learn more about how content and media permissions combine when multiple roles are assigned to a single user, please refer to Assigning multiple roles to a user.
Example: Configuring a role for read-only in Master and full access in Development
The table above illustrates different permission levels per environment. Below is an example of how to configure a single role to achieve the following setup:
Master environment → Read-only access.
Development alias → Read, Create/Edit, Delete, and Publish access.
To configure this within a single role:
Open the Role editor.
Navigate to the Environments tab.
Ensure granular environment permissions are enabled.
Configure the permissions per environment as follows:
Master
Content types → Read
Tags → Read
No Create/Edit/Delete permissions.
No Publish permissions.
Development (alias)
Content types → Read / Create/Edit / Delete.
Tags → Read / Create/Edit / Delete.
Publishing → Allow.
This configuration ensures:
Users can view production (Master) content but cannot modify or publish changes.
Users can fully manage content in the development environment, including creating, editing, deleting and publishing entries.
NOTE: environment permissions are evaluated per role. If additional roles are assigned to the same user, their permissions will be merged according to the override rules described above.
Defining different permission sets per environment
Permissions are evaluated per role. When multiple roles are assigned to a user, their environment access and permissions are merged.
If you want a user to have different permission levels in different environments (for example, read-only access in Master, but create/edit access in Staging and QA), you must:
Create separate roles that define the required permission set for each environment.
Assign all relevant roles to the user.
It is not possible to define multiple independent rule sets for different environments within a single role in a way that keeps them isolated from each other when roles are merged.
For example:
Role A → Master: Read-only.
Role B → Staging & QA: Read/Create/Edit.
Assigning both roles to a user results in:
Read-only access in Master.
Read / Create/Edit access in Staging & QA.
This approach ensures environment-specific access while maintaining predictable permission evaluation.
Migration note for existing organizations
Granular environment permissions were introduced with a toggle switch to ensure that existing organizations would not have their current role and permission assignments unexpectedly changed.
If your organization was created before granular permissions were introduced, your existing permission model may continue to behave according to the previous evaluation logic until you migrate. We recommend reviewing your roles and environment access settings to ensure they align with your intended permission structure.