> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# DryRunPro Permissions, the Granular Permission Catalogue

> DryRunPro defines 38 granular permissions across project, staging, Composer, Open Source, Docker, AWS, audit log, alerts, app connector, team, terminal, and profile modules. Bundle them into roles or grant per-user.

The **Permissions** page is the catalogue of every fine-grained permission DryRunPro recognises. There are 38 permissions across roughly a dozen modules, and they are the atomic unit that [Roles](/vortex-apps/dryrunpro/roles) bundle together. Live URL:

```
/v2/apps/dryrunpro/permissions
```

Reach it via the **User management** sub-menu in the left rail, then **Permissions**.

This page documents what each permission slug means, which module it belongs to, and which roles include it by default. Cross-link [Roles](/vortex-apps/dryrunpro/roles) for the role catalogue and [Project Users](/vortex-apps/dryrunpro/users) for how to grant per-user overrides.

## 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](/vortex-apps/dryrunpro/projects/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](/vortex-apps/dryrunpro/projects) tab and any project's metadata.                                           |
| `adobe_commerce_create`   | The [Add Adobe Commerce Cloud Project](/vortex-apps/dryrunpro/projects/add-adobe-commerce-cloud-project) wizard.                         |
| `adobe_commerce_edit`     | Editing project credentials, DRP overrides, and team assignment on [Project Overview](/vortex-apps/dryrunpro/projects/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](/vortex-apps/dryrunpro/projects/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](/vortex-apps/dryrunpro/staging) 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](/vortex-apps/dryrunpro/staging/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](/vortex-apps/dryrunpro/docker) 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.                                                          |

These permissions are only relevant to the AWS-hosted DryRunPro deployment (the canonical 247Commerce one). Self-hosted variants use a different infrastructure layer.

### 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](/vortex-apps/dryrunpro/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](/vortex-apps/dryrunpro/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`, all `adobe_staging_*`, all `adobe_compose_*`, `adobe_open_source`, `adobe_opensource_show`, all `adobe_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`.

For exact membership, see [Roles](/vortex-apps/dryrunpro/roles). The chip clusters there are the source of truth.

## 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](/vortex-apps/dryrunpro/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](/vortex-apps/dryrunpro/roles), the bundles that consume these permission slugs.
* [Project Users](/vortex-apps/dryrunpro/users), where role and direct permissions are assigned.
* [Teams](/vortex-apps/dryrunpro/teams), the team layer that gates project access (independent of permissions).
* [Add Project](/vortex-apps/dryrunpro/projects/add-adobe-commerce-cloud-project), gated by `adobe_commerce_create`.
* [Delete Project](/vortex-apps/dryrunpro/projects/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 with `adobe_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](/vortex-apps/dryrunpro/teams), or assign them directly via the [Project Users](/vortex-apps/dryrunpro/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](/vortex-apps/dryrunpro/staging/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](/vortex-apps/dryrunpro/users) 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.