Skip to main content
DryRunPro uses a four-role model: Admin, Team Leader, Developer, Tester. Each role bundles a default set of permissions from the Permissions catalogue, and each Project User is assigned exactly one role. The role determines what the user can do across the tenancy and inside specific projects. Live URL: app.vortexiq.ai/v2/apps/dryrunpro/roles This page documents the four roles, the permissions each one bundles, and the typical use case for each. Cross-link Permissions for the underlying permission catalogue and Project Users for how role assignment works at the user level.

​
What you see when you land here

The page header is a green Add Role button (top-left), then Role List in bold, then a control strip with “Show / entries” pagination, Select all, Deselect all, Columns toggle, Delete selected, and a Search field on the right. Below the controls, a single table with the four default roles (the screenshot of a real tenancy shows IDs 1 to 4):
IDTitlePermissionsAction
4Adminevery permissionView / Edit / Delete
3Team Leadermany permissionsView / Edit / Delete
2Developermost operational permissionsView / Edit / Delete
5Testerread-only + SWAT permissionsView / Edit / Delete
Each cell in the Permissions column shows a horizontal cluster of small blue chips, one per permission slug (e.g. “adobe_staging_create”, “adobe_docker_show”, “audit_logs_show”). The clusters wrap onto multiple lines for the higher-tier roles.

​
Admin role

Default permissions: every permission in the catalogue. The Admin role is the all-powers role. An Admin can:
  • Add and delete Adobe Commerce Cloud projects.
  • Manage every project’s credentials, DRP overrides, and team assignment.
  • Spin up, modify, and tear down any dryrun in any project.
  • Generate Docker snapshots and Warden packages.
  • Install and disable Magento extensions on any dryrun.
  • Manage the user roster (Project Users).
  • Manage Roles, Permissions, and Teams.
  • Configure tenancy Settings, CDN.
  • View audit logs.
  • Edit profile and password (their own, and on behalf of others).
Use Admin sparingly. Limit it to one or two engineers per tenancy who own the platform itself. For day-to-day project work, a Team Leader role is usually enough. The seeded Admin user in a fresh tenancy is the deploy-bot account (e.g. monitor@247commerce.co.uk) plus the human who set up the tenancy.

​
Team Leader role

Default permissions include (from the screenshot’s full chip cluster): project_overview_access, adobe_commerce_create, adobe_commerce_edit, adobe_commerce_show, adobe_commerce_access, adobe_staging_access, adobe_staging_create, adobe_staging_edit, adobe_staging_delete, adobe_staging_mcpm, adobe_open_source, adobe_compose_create, adobe_compose_edit, adobe_compose_show, adobe_compose_delete, adobe_opensource_create, adobe_opensource_edit, adobe_opensource_show, adobe_opensource_delete, adobe_docker_create, adobe_docker_show, adobe_docker_edit, adobe_docker_delete, 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. In plain English, a Team Leader can do everything inside the projects assigned to their teams: spin up dryruns, manage Docker, install Magento extensions, view all data, generate snapshots. They cannot change tenancy-wide settings (CDN keys, user list, role definitions); those are Admin-only. Use Team Leader for the senior engineer who owns the relationship with one customer or one set of projects. They own the operational reality of those projects without having keys to the entire tenancy.

​
Developer role

Default permissions include: project_overview_access, adobe_commerce_show, adobe_commerce_access, adobe_staging_access, adobe_staging_create, adobe_staging_edit, adobe_staging_delete, adobe_staging_mcpm, adobe_open_source, adobe_compose_create, adobe_compose_edit, adobe_compose_show, adobe_compose_delete, adobe_opensource_show, adobe_docker_create, adobe_docker_show, adobe_docker_edit, adobe_docker_delete, aws_access, aws_create, aws_show, user_alert_edit, create_your_own, app_connector. The Developer role is the day-to-day engineer’s role. They can:
  • Spin up dryruns on any project they have team access to.
  • Install / disable Magento extensions on dryruns.
  • Generate Docker snapshots and Warden packages.
  • SSH into running container fleets.
  • View Cloud Project credentials (read-only, masked).
  • Edit their own User Alerts.
They cannot:
  • Add or delete Adobe Commerce Cloud projects (no adobe_commerce_create / adobe_commerce_delete).
  • Manage other users.
  • Edit tenancy CDN settings.
  • Change DRP Composer overrides on a project (those are Team Leader+).
Use Developer for the engineering team that does the actual building. Most users in a tenancy are Developers.

​
Tester role

Default permissions include: adobe_staging_access, adobe_staging_show, audit_logs_show, profile_password_edit. Tester is the QA / read-only role. A Tester can:
  • View any dryrun’s status, URL, and SWAT report.
  • View build logs.
  • Read audit logs.
  • Edit their own profile and password.
They cannot:
  • Spin up new dryruns.
  • Modify any project state.
  • Generate Docker packages.
  • See Cloud Project credentials.
Use Tester for QA engineers, customer-side stakeholders, and any contractor who needs visibility but should not be able to change anything.

​
Role inheritance and effective permissions

There is no role inheritance hierarchy. A Tester is not a subset of Developer; they are independent role definitions, each starting from zero and adding permissions. The chip cluster on each row is the literal complete permission set. A user’s effective permissions are the union of:
  1. Their role’s default permissions.
  2. Any per-user permission overrides set on their Project User record.
  3. Any team-level permission grants from teams they belong to.
In most tenancies the role default is enough; per-user overrides are reserved for special cases (e.g. “this Tester also needs to spin up dryruns for one project”).

​
Adding a custom role

Click the green Add Role button at the top of the page to create a new role. The Add Role dialog asks for:
  • Title, the human-readable role name.
  • Permissions, a multi-select against the Permissions catalogue.
Click Save and the role appears in the table with a fresh ID. You can then assign it to users from the Project Users Edit dialog. Custom roles are useful for niche use cases:
  • Release Manager, can spin up dryruns and run SWAT reports but cannot modify Magento extensions.
  • Customer Read, only audit_logs_show and adobe_staging_show, given to a customer-side stakeholder for transparency.
  • Migration Lead, full Developer permissions plus adobe_commerce_edit for ad hoc project credential rotation.

​
Editing and deleting a role

Click the blue Edit action on a row to change the title or the permission set. Save commits. Click the red Delete action to remove a role. Pre-condition: the role must have zero users assigned. If any Project User is on the role, deletion is blocked and the dialog tells you which users to reassign first. The four default roles (Admin, Team Leader, Developer, Tester) cannot be deleted; the Delete action is greyed out. They can be edited (you can extend or trim their permission set), but the role itself is permanent.
  • Permissions, the catalogue of permission slugs that roles consume.
  • Project Users, where roles are assigned to users.
  • Teams, the team layer that gates project access independently of role.
  • Add Project, the action that requires adobe_commerce_create.
  • Delete Project, the action that requires adobe_commerce_delete.

​
Frequently asked questions

Can a single user have multiple roles? No. One user, one role. To layer additional capabilities, use per-user permission overrides on the Project User record or grant additional permissions through team membership. What is the practical difference between Team Leader and Developer? A Team Leader can manage the projects assigned to their teams (edit credentials, change DRP overrides, change team assignment). A Developer can operate inside those projects (spin up dryruns, install extensions, generate snapshots) but cannot change project-level configuration. Why would I create a custom role instead of using one of the four defaults? When you have a specialised job function that does not fit any default. The most common is a Release Manager who has Developer permissions plus the right to promote a dryrun back into Adobe staging. Can a Tester run a SWAT report? A Tester can view a SWAT report that has already been generated. Triggering a fresh SWAT report run requires adobe_staging_edit on most tenancies, which is not in the Tester default. Add the permission via Permissions override if needed. Can I revoke a permission from the Admin role? Yes, via Edit on the Admin row. The Admin role is editable; only the role itself is undeletable. In practice you should not strip Admin permissions unless you are setting up a constrained environment with a different “super-admin” role. My role has a permission for audit_logs_show but the user cannot see audit logs. Audit logs are also gated by tenancy settings (some tenancies hide audit logs from anyone except Admins for compliance reasons). Check Settings, then look at the user’s effective permissions in their Edit dialog. The chip cluster on Admin is huge. Can I see it as a list instead? Yes. Click View on the Admin row to open a read-only role detail page that lists permissions one per line. Are role definitions versioned? Changes to a role are recorded in the platform-level audit log (added permissions, removed permissions, by whom, when). The role itself is not versioned, only the change history.