Skip to main content
Teams in DryRunPro is the layer that lets one engineering organisation manage many enterprise Adobe Commerce Cloud customers without granting every engineer access to every project. A team is a group of users that gets assigned to one or more projects collectively. Live URL: 
/v2/apps/dryrunpro/teams
Reach it via the User management sub-menu in the left rail, then Teams. (The page header reads “Organization List” because internally a team is a “Organization”, but the left-rail label says “Teams” and the rest of the UI uses the team terminology.) This page documents the team model, how to create a team, how to add users, how to assign a team to projects, and the real-world examples from a live agency tenancy (Cakebox, Blitz, BDFC).

​
Why teams matter

A Magento agency typically operates ten-plus Adobe Commerce Cloud customer projects in a single DryRunPro tenancy. Each customer has their own engineering crew (the agency’s internal team plus, sometimes, the customer’s own engineers). If you grant access on a per-project basis, the per-user permission matrix becomes unmanageable. If you grant access tenancy-wide, every engineer can see every customer’s data, which is unacceptable for confidentiality reasons. Teams resolve the tension. Each team is a named group (“Cakebox”, “Blitz”, “BDFC”). Each team gets a list of member users. Each project gets a team assignment on its card. A user has effective access to a project if they are a member of any team assigned to that project (or directly assigned to the project on the Project Users record). The result: you bring on a new engineer, you add them to the relevant team, and they immediately see all projects that team is assigned to without further per-project clicks. You off-board an engineer, you remove them from the team, and they lose access to all those projects at once.

​
What you see when you land here

The page header is a green Add Organization button (top-left), then Organization 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:
ColumnWhat it shows
IDThe integer team ID. Sortable.
NameThe team’s display name (e.g. “Cakebox”, “Blitz”, “BDFC”).
OwnerThe user who created or owns the team (e.g. “Alex S”).
ActionThree buttons: green View, blue Edit, red Delete.
A real agency tenancy in the screenshot shows three teams:
IDNameOwnerAction
3BDFCAlex SView / Edit / Delete
2CakeboxAlex SView / Edit / Delete
1BlitzAlex SView / Edit / Delete
These names are real and worth explaining. Cakebox is the team that handles both Eggfree Cake Box Limited Azure and Eggfree Cake Box Ambala (two Adobe Commerce Cloud projects for the same UK retailer). Blitz handles Blitz Corporation Ltd. BDFC handles the Bahrain Duty Free Company projects (Dublin and the W.L.L. variant). Each team is named after the customer (or customer group) they serve.

​
Creating a team

Click the green Add Organization button at the top. The Add Organization dialog asks for:
  • Name, the human-readable team name. Best practice is to name after the customer or customer group (e.g. “Cakebox”, “Soak and Sleep”, “Krispy Kreme”).
  • Owner, picked from the Project Users roster. The owner is the user who is responsible for the team. They get implicit edit rights on the team itself.
  • Members, multi-select from the user roster.
  • Description (optional), a short note about the team’s purpose.
Click Save and the team appears in the table.

​
Adding users to a team

Two ways:
  1. From the team’s Edit dialog, click Edit on the row, scroll to Members, multi-select the users, save.
  2. From a user’s Edit dialog, click Edit on the user in Project Users, scroll to Teams, multi-select the teams, save.
The two paths are equivalent; pick whichever is faster for the operation you are performing.

​
Assigning a team to a project

This is the operation that gates project access. Two paths:
  1. From the project card on the Projects tab, the Team dropdown at the bottom of the card. Pick the team and the assignment is committed instantly.
  2. From the Project Overview page, the Assigned Team dropdown in the Project Details panel, then click the Assign Team button.
A project can have one team assigned at a time. To grant access to engineers from two teams, either:
  • Move all engineers into a single combined team.
  • Use direct per-user project assignment via Project Users Edit dialog (rare, but supported).
The “No team” option in the dropdown is the explicit unassigned state. A project with No team has zero team-based access; only users with direct project assignments (and Admins, who have implicit access to everything) can see it.

​
Effective access calculation

When DryRunPro evaluates whether a user can see a project, it walks this logic:
  1. Is the user an Admin? Yes → access granted.
  2. Is the user directly assigned to the project on the Project Users record? Yes → access granted.
  3. Is the user a member of any team that is assigned to the project? Yes → access granted.
  4. Otherwise → access denied.
The user does not need to be the owner of a team or a Team Leader by role. Membership of any team assigned to the project is sufficient. Note that team membership grants project visibility, not all permissions on that project. The user’s role and direct permissions still gate the actions they can perform. A Tester on the Cakebox team can see the Cakebox projects but cannot spin up dryruns on them; a Developer on the same team can.

​
Editing and deleting a team

Click the blue Edit action on a row to:
  • Rename the team.
  • Change the owner.
  • Add or remove members.
  • Edit the description.
Click the red Delete action to remove a team. Pre-condition: every project assigned to the team must be reassigned (to another team, or to “No team”) before deletion succeeds. The dialog tells you which projects are blocking and lets you click through to reassign. After deletion:
  • The team’s members are not affected as users; only their team membership is dropped.
  • Projects that were assigned to the team revert to “No team”.
  • The audit log records the deletion with deleter, timestamp, and previous member roster.

​
Renaming a team

Renaming is supported via Edit. The new name appears immediately on every project card that the team is assigned to (the dropdown selection is preserved by team ID, not name). If you rename a team that has been referenced in saved User Alert filters, the alerts continue to work because they bind to ID, not name. The display label updates on the next page load.

​
Audit and compliance

Every team operation is recorded in the platform audit log:
  • Team created (by, when).
  • Member added / removed.
  • Owner changed.
  • Project assigned / unassigned to team.
  • Team renamed.
  • Team deleted.
The audit log surface is at User management, Audit Logs in the left rail.

​
Team naming conventions

The screenshots from the live agency tenancy follow these conventions, which we recommend:
  • Customer-first names, named after the customer brand (Cakebox, Blitz, BDFC) so that anyone scanning the project list immediately understands who the team is for.
  • Short, three to ten characters, for legibility in the dropdown on the project card.
  • No prefixes (avoid “Customer-Cakebox” or “Team Cakebox”). The team’s role is implicit from being on this page.
  • One team per customer or customer group, even if you have to rename later. Easier to manage than per-project teams.
If you operate as an agency that handles dozens of customers, consider naming teams after the engineering pod rather than the customer when one pod handles multiple customers. For example, “Pod Alpha” assigned to four projects, “Pod Beta” to three. This is a stylistic preference; both work.
  • Project Users, where users are added to teams from the user side.
  • Roles, the role layer that gates actions independently of team-based project visibility.
  • Permissions, the underlying permission slugs.
  • Projects, the team dropdown on project cards.
  • Project Overview, the Assigned Team dropdown.

​
Frequently asked questions

Why does the page say “Organization List” when the left-rail label is Teams? Legacy. The internal data model calls a team an Organization, and the list page header was not updated when the rail label was renamed. The terminology will converge in a future release. For all practical purposes, Organization on this page = Team in the rest of the UI. Can a project be assigned to multiple teams at once? No. One project, one team assignment. To grant access to engineers from two teams, merge them into a single team or use direct per-user project assignment via Project Users. Can a user belong to multiple teams? Yes. A user can be a member of any number of teams. Their effective project access is the union of all the teams’ project assignments. Why is the team owner required? The owner is a single person who has implicit edit rights on the team and is the escalation contact if the team needs admin attention. In most tenancies this is the agency lead who set up the team. What happens if I delete the user who owns a team? The team itself stays intact, but the Owner field becomes orphaned. DryRunPro auto-reassigns ownership to the deleting Admin (or to the tenancy’s primary Admin if the deleter is not available). You can edit the team afterwards to set a new owner. Can I assign a project to “No team” if I want only Admins to see it? Yes. With No team and no direct user assignments, only Admins see the project. Useful for sensitive customer onboarding where you do not yet want to grant the standard team access. Can I see which projects are assigned to a team? Click View on the team row to open a read-only team detail page that lists members and assigned projects. (The team Edit dialog does not show project assignments; you have to use View.) Are teams visible to non-Admin users? Members of a team can see the team’s name and project assignments via the projects they have access to. They cannot edit team membership or rename. Only Admins (and Team Leaders for their own teams) have edit rights.