What you see when you land here
The page header is Permission List in bold, with a “Show / entries” pagination control below it and a Search field on the right. Below the controls, a single table with columns ID and Title. Each row is one permission slug. The list, ordered by ID descending in the screenshot:| ID | Title (slug) |
|---|---|
| 38 | profile_password_edit |
| 37 | staging_administer_access |
| 36 | staging_terminal_access |
| 35 | team_members_access |
| 34 | app_connector |
| 33 | create_your_own |
| 32 | user_alert_edit |
| 31 | aws_delete |
| 30 | aws_show |
| 29 | aws_edit |
| 28 | aws_create |
| 27 | aws_access |
| 26 | adobe_docker_delete |
| 25 | adobe_docker_edit |
| 24 | adobe_docker_show |
| 23 | adobe_docker_create |
| 22 | adobe_opensource_delete |
| 21 | adobe_opensource_show |
| 20 | adobe_opensource_edit |
| 19 | adobe_opensource_create |
| 18 | adobe_open_source |
| 17 | adobe_compose_delete |
| 16 | adobe_compose_show |
| 15 | adobe_compose_edit |
| 14 | adobe_compose_create |
| 13 | adobe_commerce_compress |
| 12 | adobe_staging_mcpm |
| 11 | adobe_staging_delete |
| 10 | adobe_staging_edit |
| 9 | adobe_staging_show |
| 8 | adobe_staging_create |
| 7 | adobe_staging_access |
| 6 | adobe_commerce_delete |
| 5 | adobe_commerce_show |
| 4 | adobe_commerce_edit |
| 3 | adobe_commerce_create |
| 2 | adobe_commerce_access |
| 1 | project_overview_access |
Permission groups
The 38 permissions cluster into ten functional groups. Below, each group is documented with the permissions it contains and what each one gates.Project access
| Slug | Gates |
|---|---|
project_overview_access | The Project Overview page. Without this, the View Details link on a project card is greyed out. |
Adobe Commerce (project) management
| Slug | Gates |
|---|---|
adobe_commerce_access | Read access to the Projects tab and any project’s metadata. |
adobe_commerce_create | The Add Adobe Commerce Cloud Project wizard. |
adobe_commerce_edit | Editing project credentials, DRP overrides, and team assignment on Project Overview. |
adobe_commerce_show | Viewing the per-project detail page contents (Adobe Cloud Environments, project credentials in masked form). |
adobe_commerce_delete | The Delete Project workflow. |
adobe_commerce_compress | Triggering project-level data compression for storage efficiency. |
Staging (dryrun) management
| Slug | Gates |
|---|---|
adobe_staging_access | Read access to the Dryrun Environments tab. |
adobe_staging_create | Creating a new dryrun (Create Staging Environment button). |
adobe_staging_edit | Editing a running dryrun’s settings (CDN mode, expiry, container start / stop). |
adobe_staging_show | Viewing Staging Detail. |
adobe_staging_delete | Tearing down a dryrun. |
adobe_staging_mcpm | Magento Cloud Patch Manager integration on a dryrun. |
Composer overrides
| Slug | Gates |
|---|---|
adobe_compose_create | Adding new DRP Composer overrides to a project. |
adobe_compose_edit | Editing existing overrides. |
adobe_compose_show | Viewing the override list. |
adobe_compose_delete | Removing overrides (the Clear all DRP overrides button). |
Magento Open Source extensions
| Slug | Gates |
|---|---|
adobe_open_source | Top-level access to the Magento Open Source extension surface. |
adobe_opensource_create | Adding a Magento extension to the dryrun. |
adobe_opensource_edit | Editing extension config. |
adobe_opensource_show | Viewing the installed extension list. |
adobe_opensource_delete | Uninstalling an extension. |
Docker
| Slug | Gates |
|---|---|
adobe_docker_create | Generating a Docker snapshot or Warden package. |
adobe_docker_edit | Editing Docker container config (resource limits, etc.). |
adobe_docker_show | Viewing the Docker packages list and downloading. |
adobe_docker_delete | Deleting a Docker package (rare; usually deleted with the parent dryrun). |
AWS infrastructure
| Slug | Gates |
|---|---|
aws_access | Top-level access to the AWS-side infrastructure surface (where dryrun containers live). |
aws_create | Provisioning new AWS resources. |
aws_edit | Modifying AWS resources. |
aws_show | Viewing AWS resource state. |
aws_delete | Decommissioning AWS resources. |
User-level controls
| Slug | Gates |
|---|---|
user_alert_edit | Editing the user’s own User Alerts. |
create_your_own | Access to the Create your own top-tab in the left rail. |
app_connector | Configuring the App Connector integrations (e.g. Slack, JIRA). |
team_members_access | Reading the Teams member roster. |
staging_terminal_access | Opening an SSH or Cloud CLI terminal session against a dryrun. |
staging_administer_access | The administer / Site-Wide Analysis Tool surface. |
profile_password_edit | Editing the user’s own profile and password. |
Default role allocation
The four default Roles bundle these permissions as follows:- Admin has every permission.
- Team Leader has all
adobe_*,aws_access,aws_create,aws_edit,aws_show,aws_delete,user_alert_edit,create_your_own,app_connector,team_members_access,staging_terminal_access,staging_administer_access. (Effectively everything except some niche compress / Adobe-only flags.) - Developer has
project_overview_access,adobe_commerce_show,adobe_commerce_access, alladobe_staging_*, alladobe_compose_*,adobe_open_source,adobe_opensource_show, alladobe_docker_*,aws_access,aws_create,aws_show,user_alert_edit,create_your_own,app_connector. - Tester has
adobe_staging_access,adobe_staging_show,audit_logs_show(where present),profile_password_edit.
Granting a permission to a single user
Sometimes you do not want to change the role definition (which would affect every user on that role); you just want to grant one extra permission to one user. The Project Users Edit dialog has a “Direct permissions” multi-select. Tick the extra permission slug, save, and the user gets it as an override on top of their role. The user’s effective permissions become the union of role + direct permissions + team-level grants.Custom permissions
The 38 permissions in the catalogue are seeded by DryRunPro at deploy time. The platform does not allow tenancy admins to create new permission slugs; that requires a code change. If you need a new permission for a custom workflow, raise a feature request through your DryRunPro account manager.Cross-links
- Roles, the bundles that consume these permission slugs.
- Project Users, where role and direct permissions are assigned.
- Teams, the team layer that gates project access (independent of permissions).
- Add Project, gated by
adobe_commerce_create. - Delete Project, gated by
adobe_commerce_delete.
Frequently asked questions
Why do I see 38 permissions in the table but the role chips show fewer? The role chips show the permissions assigned to that role. A role rarely has all 38; only Admin does. The catalogue is the universe; each role is a subset. Can I re-order the permission list? No. The list is sorted by ID descending and is not reorderable from the UI. The IDs are stable across deployments, so you can reference them in scripts. The user has the role withadobe_staging_create but cannot spin up a dryrun. Why?
Permission is necessary but not sufficient. The user also needs team access to the project (or a direct project assignment). A Developer who is not on any team that includes Project X cannot spin up dryruns on Project X regardless of their role. Add the user to a team via Teams, or assign them directly via the Project Users Edit dialog.
Why is adobe_staging_mcpm separate from adobe_staging_edit?
Magento Cloud Patch Manager integration is a sensitive operation (it can patch the Magento core on the dryrun). It is split out so admins can grant the rest of the staging permissions without granting MCPM. Most Developers do not need MCPM.
What does staging_administer_access actually unlock?
The Site-Wide Analysis Tool link on the Staging Detail page. Without this permission the link is hidden.
Can a permission be revoked from a single user via this page?
Not from this page. The Permissions list is read-only / catalogue-only. To revoke a permission for a specific user, edit the user’s Project User record and untick the direct-permission entry, or change their role.
Are permissions inherited from team membership?
Some are. Teams can carry team-level permission grants that apply to every member; this is typically used to grant a tester role’s user the right to spin up dryruns when they are working on a specific project. Most tenancies do not use team-level grants; user-level overrides are simpler.
Why are AWS permissions in the catalogue when my deployment is on a different cloud?
The catalogue is platform-wide, not deployment-specific. AWS permissions are no-ops on non-AWS deployments. Future releases will surface deployment-relevant permissions only.