Managing Permissions | MuleSoft Documentation
# Managing Permissions
This section explains how permissions work across different products and APIs managed from the Anypoint Platform.
To manage permissions, you must have the Organization Administrator permission in your organization, have the Organization Administrator permission over one of the business groups of your organization, or have API Version Owner permissions and want to manage user permissions for an API version, a business group or the entire organization.
## How Permissions Work in Anypoint Platform
In the Anypoint Platform, users belong to organizations and have sets of permissions. These permissions are assigned using teams or roles (deprecated), or by granting permissions to users individually.
The Teams feature enables you to create groups of users and then assign the members of those groups certain permissions across multiple business groups. As an Organization Administrator, you can create and modify teams and assign cascading permissions according to organizational structure.
Each role (deprecated) contains a list of permissions that define what a user with that role can do with the specific resources it scopes. Certain roles include a set of default permissions. As an organization administrator, you can create your customized roles and assign the permissions accordingly.
Depending on the product, you can grant permissions directly to a specific user, without the need for roles or teams.
### Understanding Permissions
Depending on which products you have in Anypoint Platform, every new organization, team, and business group is assigned a set of default _permissions_ when first created:
  1. **Product Permissions**
     * Default permissions for each Anypoint Platform product (Runtime Manager, Data Gateway, and so on) are _environment specific_ , granting users the ability to do something within a particular environment but not within the entire organization. These default product permissions are assigned to teams, custom roles, or CloudHub roles.
  2. **API Permissions**
API Permissions vary depending on the API Manager version you are using.
    1. **Permissions in API Manager 1.x**
       * Default permissions for each API managed from Anypoint Platform are either specific to an API version or extended to all versions. You can manage user access based on a particular API version, but you cannot extend those permissions to the entire organization. To grant user permissions to all APIs, add them to teams that have the API Versions Owner and Portals Owner permissions.
       * You can assign user permissions to edit or view individual API versions or API portals using the API Version Owner and the Portal Viewer permissions.
These two API permissions grant the same permissions as the API Versions Owner and Portals Viewer roles, but they are limited to the API and version that you defined. For more information about these specific scopes, see Roles.  
---  
    2. **Permissions in API Manager 2.x**
       * Default permissions for each API managed from API Manager grant permission to access a specific environment and a specific resource (policies, alerts, and so on). If a permission to an environment is granted to a user, it gives the user access to that environment immediately. For example, if you want to grant a user permission to create and edit alerts, you assign them the Manage Alerts permission.
       * To create an API in Exchange, users need either the Exchange Admin permission or Exchange Contributor permission.


Since _API versions_ and _Products deployment environments_ are grouped under organizations (and optionally under business groups too), to access them you need to have an account that owns the necessary permissions and that belongs to its corresponding organization or business group (if such resource exists).
Roles assigned at the root organization level can reference only resources that are at the root organization level, and roles that belong to a business group can reference only resources within that business group.
A user that owns any role of a business group is implicitly granted membership in that business group. Once a user belongs to a business group within an organization, the only way to assign entitlements to that same user in a different business group is by assigning it a role within that second business group.  
---