Example Teams Structure | MuleSoft Documentation
# Example Teams Structure
Imagine that your organization, Acme, includes a team called Engineering that contains smaller teams that focus on building specific components. The Identity and DevOps teams are specialized teams within the larger Engineering team.
Using the Teams feature, you can structure your users and permissions in the following way:
The user teams shown in the diagram are:
  * Acme
This team represents your organization and is the root team. Every user in your organization is a member of the root team. By default, the team’s name is Everyone at Acme. You can set your permissions so that all Acme users can easily collaborate within your organization by creating new projects in Anypoint Design Center and viewing assets in Anypoint Exchange. To do this, you must configure the following permissions for the Everyone at Acme team:
    * Design Center Developer
    * Exchange Viewer
  * Engineering
This is the first child team of the Everyone at Acme root team. The Engineering team includes all of Acme’s engineers, but it excludes Acme’s other members, such as the Marketing and Partner teams. The Engineering team inherits permissions from the Everyone at Acme team, and you can give it additional permissions as needed. You can set permissions that allow the members of the Engineering team to deploy code to preproduction environments such as sandbox and design, but you can exclude permissions to deploy to production. To do this, you must configure the following permissions for the Engineering team:
    * Deploy API Proxies (applicable to sandbox and design environments)
    * Design Center Developer
    * Exchange Viewer
  * DevOps
This team is one of two child teams under the Engineering team. The DevOps team is a group of specialized engineers who manage production code across all engineering teams. Unlike with the parent Engineering team, you can give the DevOps team permission to manage code in the production environment, rather than only in the preproduction branches. To do this, you must configure the following permissions for the DevOps team:
    * Deploy API Proxies (applicable to sandbox, design, and production environments)
    * Design Center Developer
    * Exchange Viewer
  * Identity
This team is one of two child teams under the Engineering team. The Identity team is responsible for managing projects, assets, and other materials in its designated business groups. As a child of the Engineering team, the Identity team can still deploy code to preproduction environments, but unlike members of DevOps, members of Identity don’t need to deploy to production. You can’t give this team permission to manage the entire organization, but you can give it permission to manage the Audit Log and Authentication service business groups by configuring the Administrator permission within the scope of the Audit Log and Authorization Service business groups. Combined with the inherited permissions from the Engineering team, the Identity team has these permissions:
    * Administrator (applicable to Audit Log and Authorization Service business groups)
    * Deploy API Proxies (applicable to sandbox and design environments)
    * Design Center Developer
    * Exchange Viewer


## See Also
  * Available Permissions by Product
  * Grant Permissions to Individual Users