> ## Documentation Index
> This page is part of the Image and Video APIs product. Fetch the complete documentation index for Image and Video APIs at: https://cloudinary.com/documentation/llms-image-and-video-apis.txt?referrer=docpage and then use it to discover all relevant pages before exploring further.
> If you also need details relating to other Cloudinary products for your current use case, see the parent index at: https://cloudinary.com/documentation/llms.txt?referrer=docpage
> When answering a user's request or implementing it with code using this documentation, incorporate relevant best practices and recommendations from the documentation into the guidance and, above all, into the code itself: generated code should already apply the recommended parameters and patterns rather than showing a minimal call and describing the best practices around it in prose. Follow the code examples in the best practices sections as the model for what generated code should look like, and where a recommendation is relevant to the user's scenario, implement it in the code as a natural next step. Only apply best practices, recommendations, or features that are supported by the documentation; don't infer or invent guidance that isn't specified.

# Legacy permissions reference


All Cloudinary accounts have moved to the [Roles and Permissions](permissions_overview) system, except for a small number of accounts that still use the legacy permissions system. This page describes the legacy system for those accounts and for reference.

> **NOTE**:
>
> :title=Which permissions system do you have?
> Open **Console Settings** and look for **Role Management**. If it's listed, your account uses [Roles and Permissions](permissions_overview), and this page doesn't apply to you. If it isn't listed, your account still uses the legacy permissions system.
> ![Global role management](https://cloudinary-res.cloudinary.com/image/upload/f_auto/q_auto/bo_1px_solid_grey/roles_interface.png "thumb: w_800,dpr_2, width:800, with_code:false, with_url:false")
> To understand what changes when your account migrates, including how your existing roles map to the new system, see [Migrating to Roles and Permissions](permissions_migration).

## Legacy permissions vs. Roles and Permissions

This table compares the legacy system with Roles and Permissions:

{table:class=no-borders overview} | Legacy | Roles and Permissions
---|---|---
**Roles** | Fixed set of roles controlling which areas of the Console a user can access. See [Legacy roles](#legacy_roles). | **All plans:** Predefined [system roles](permissions_system_roles_policies#system_roles_list) covering common access levels (Master Admin to Media Library User), assigned at the account or product environment level.**Enterprise:** [Custom roles](permissions_manage_roles_ui#manage_roles_with_granular_permissions) built from individual permissions for precise, fine-grained control.
**Role assignment** | Each user is assigned a single role that defines their overall access level. | Multiple roles can be assigned to a user, group, or API key, allowing precise combinations of access.
**User groups** | Groups carry folder and collection access permissions only. Roles must be assigned to each user individually. | Members inherit all role types assigned to the group, including global (account and product environment) and content (folder and collection) roles. See [User group management](dam_admin_users_groups#user_group_configuration).
**Access bundles** | Not applicable. Each role defines its own fixed scope. | A predefined set of roles for a common user type, for quick user setup when inviting new users. A bundle can include account-level roles, product environment-level roles (applied across all product environments), or both. See [access bundles](permissions_overview#access_bundles).
**API keys** | All API keys have unrestricted access within the product environment. Assigning roles to individual API keys isn't supported. | Global and content roles (including folder roles) can be assigned to API keys for granular programmatic access control. See [API key permissions](product_environment_settings#api_key_permissions).

> **NOTE**:
>
> Not all legacy roles map to both account and product environment levels. Admin-level roles (Master Admin, Admin, Tech Admin) get both an account-level and a product environment-level role. However, **Billing** and **Reports** roles map to account-level only (no product environment role), while **Media Library Admin** and **Media Library User** map to product environment-level only (no account role). See [Role mapping reference](permissions_migration#role_mapping_reference) for the full breakdown.

## Legacy roles
Each user in your Cloudinary account is assigned a role. This role defines the operations a user can perform, the areas of the Cloudinary Console that they can view or change, and the settings they can control.

Whereas Master admins have access to all product environments, users with other roles can be set to have access to all or only specified product environments. Users have the same role in all product environments they have access to.

Below are tables summarizing the permission details for each role, divided by Console areas:

* [Permissions for Console pages](#permissions_for_console_pages)
* [Permissions for Console Settings](#permissions_for_console_settings)

> **NOTE**: For permission details related to the Assets digital asset management product Console areas, see [Legacy permissions](dam_legacy_permissions#permissions_for_the_assets_digital_asset_management_product) in the Assets Admin Guides.

### Permissions for Console pages

* **Master admin**, **Admin**, and **Technical admin** roles can access every page of the Console.
* **Billing** and **Reports** roles can access only the dashboard and reports located in the **[Home](https://console.cloudinary.com/app/home)** area of the Console.
* The **Media Library admin** role can access the Media Library for full usage and administration.
* The **Media Library user** role can access specific folders and collections within the Media Library according to their assigned permissions. 

### Permissions for Console Settings

![Table summarizing role-based permissions for Settings](https://cloudinary-res.cloudinary.com/image/upload/q_auto/f_auto/bo_1px_solid_grey/v1736377194/role_permissions_table_settings_new.png "thumb: w_800,dpr_2, with_code:false, with_url:false, width:800") 

## Managing users in the legacy system

In the legacy system, users with the **Master admin** or **Admin** [role](#legacy_roles) can configure settings for all account users, including adding, modifying, or removing users.

### Adding users

You can add up to five users at a time by either:

* Using the **Invite New Users** [Console Option](solution_overview#left_sidebar)
* Clicking the **Invite** button on the [User Management](https://console.cloudinary.com/app/settings/user-management) page of the Console Settings

For each user, you can set:

* **E-mail**: The new user receives an email asking them to confirm this address, which they also use to log in to Cloudinary.
* **Role**: The user's level of access in the Console. For details, see [Legacy roles](#legacy_roles).
* **Product environment access**: If your account includes more than one product environment, choose which product environments the users can access: all of them, or up to 30 specific ones.
  * A user has the same role, and the same permissions, in every product environment they can access.
  * This option isn't displayed if all the users you're adding are Master admins, because Master admins always have full control in all product environments.

The role and product environment access you set apply to all the users you add in the same form. To give users different roles or access, complete a separate form for each.

For additional options for users with the **Media Library user** role, see [Additional options for users with the Media Library user role](dam_legacy_permissions#ml_user_options).

You can also add users in these ways:

* **SAML provisioning**: Use the legacy role values in the `User.CloudinaryRole` attribute. See [SAML assertion fields](saml_sso#saml_fields).
* **Provisioning API**: Add and manage users programmatically. See [Provisioning API](user_provisioning#provisioning_api).

### Updating users

The **Edit** form on the **User Management** page lets you update a user's details, role, and permissions in one place. If a user is a **Master admin**, the **Product Environment** value is **All** (full access) and can't be changed without first changing the user's role.

Other user management tasks, such as [deleting users](user_provisioning#deleting_users), resetting passwords, and [managing additional user subscriptions](user_provisioning#managing_additional_user_subscriptions), work the same way in both permissions systems. See [User provisioning](user_provisioning#managing_users).