Granular Permissions
You can grant users permissions to assets and taxonomies by assigning roles in the repository, but you can further refine access through granular permissions applied according to asset type and taxonomy category.
Note:
- Legacy repositories (created before February 2021) don't support granular permissions. You must convert your repository to take advantage of this feature.
- You can't refine the permissions of the repository owner or members assigned the Manager role.
This topic covers the following information:
- Permissions Granted with Repository Roles
- Permissions Granted with Site Roles
- Task Permissions Granted with Repository Roles
- Custom Editorial Roles
- Granular Permissions
- Default Granular Permissions
- Parent and Child Category Granular Permissions
- User and Group Granular Permissions
- Granular Permissions Needed for Tasks
- Use Case Example for Taxonomy Category Granular Permissions
Permissions Granted with Repository Roles
When you add a member to the repository and assign them a role, the following asset permissions are selected for "Any Type".
Role | View | Update | Create | Delete |
---|---|---|---|---|
Viewer | ![]() |
|||
Contributor | ![]() |
![]() |
![]() |
![]() |
Manager | ![]() |
![]() |
![]() |
![]() |
When you add a member to the repository and assign them a role, the following taxonomy permissions are selected for "Any category".
Role | View | Categorize | Create Site |
---|---|---|---|
Viewer | ![]() |
||
Contributor | ![]() |
![]() |
![]() |
Manager | ![]() |
![]() |
![]() * |
* The Create Site permission granted to repository contributors and managers allows them to create a site in any non-site category available in the repository, assuming they have an application role that allows them to create sites and they have access to site templates.
Permissions Granted with Site Roles
For sites that don't use site security taxonomies, anyone added as a member of the site is added to the repository as a viewer.
For sites that do use site security taxonomies (SST sites), when someone is added as a member of the site, they're automatically added to one of the site content groups based on the role they're assigned. A person given the viewer or downloader role is assigned to the site content viewer group. A person given the manager or contributor role is assigned to the site content contributor group. These groups provide the following asset permissions for "Any Type".
Role | View | Update | Create | Delete |
---|---|---|---|---|
Viewer or Downloader | ![]() |
|||
Contributor or Manager | ![]() |
![]() |
![]() |
![]() |
When you add a member to the site and assign them a role, the following taxonomy permissions are selected for the site category.
Role | View | Categorize | Create Site |
---|---|---|---|
Viewer or Downloader | ![]() |
||
Contributor or Manager | ![]() |
![]() |
Task Permissions Granted with Repository Roles
When you add a member to the repository and assign them a role, they can perform the following tasks.
Task | Viewer | Contributor | Manager |
---|---|---|---|
View the repository and all the assets | ![]() |
![]() |
![]() |
Submit assets for review in workflow | ![]() |
![]() |
![]() |
Move assets through workflow
* You need at least Viewer access to the repository, plus any required workflow role. |
![]() * |
![]() * |
![]() * |
Create or upload assets
* You need at least Contributor access to the repository to create the asset, and the asset type must be associated with the repository. |
![]() * |
![]() * |
|
Edit assets (including associating categories, tags, collections, properties, uploading new versions of digital assets, and, for digital asset repositories, channels) | ![]() |
![]() |
|
Delete assets | ![]() |
![]() |
|
Change repository membership, roles, and granular permissions | ![]() |
||
Edit the repository (including associating asset types, taxonomies, languages, content connectors, workflows, and, for digital asset repositories, publishing channels, and translation connectors) | ![]() |
||
Publish assets (digital asset repositories only)
* You need at least Viewer access to the repository, plus at least Contributor access to the publishing channel used to publish the asset |
![]() * |
![]() * |
![]() * |
Create sites
Repository contributors and managers can create standard or SST sites in the repository. Users with the appropriate granular permission can create SST sites in the repository. |
![]() |
![]() |
Custom Editorial Roles
Create custom editorial roles to easily assign granular permission sets that you can apply to multiple repositories. Additionally, if you need to change the permission set, you can edit the role and the changes will apply to all repositories that use the editorial role.
Granular Permissions
For members assigned Viewer or Contributor roles, you can further refine permissions according to asset types and taxonomy categories. After you refine permissions, their role is listed as Custom. You can also save the refined granular permissions set as an editorial role.
Asset type permissions are treated as one permission group, while taxonomy category permissions are treated as another. Within each permission group, the permissions are treated as if there is an "or" between them. For example, a user might have asset type permissions that allow them to view assets of asset type "Article" or edit assets of asset type "Press Release" or view assets of asset type "Author Image". If you add taxonomy category permissions to that, each permission group is treated separately, as if there is an "and" between the two groups. That means the user has access to assets that are one of the selected asset types and have been categorized with one of the selected categories or are uncategorized. Continuing with our example user, if we add taxonomy category permissions, the user would be able to access assets of the selected asset types only if they were also (there's the "and" between the two groups) categorized with the category "Fiesta" or (there's the "or" within the same group) the category "Mustang" or if they were uncategorized.
Note:
- You can add up to 50 asset type rules and up to 30 taxonomy category rules to a single permission set.
- In the Categories tab of the asset filter panel, users see a list of all categories associated with any asset they have access to. This means they might see the name of a category to which they don't have access, but they won't be able to see assets assigned with just this category.
Taxonomy category permissions also include a Create Site permission for site security taxonomies. You can select this permission when you add a non-site category from a site security taxonomy. Users with a custom role that includes the Create Site permission can create SST sites in the repository under the selected category.
Default Granular Permissions
The permissions you apply to Any Type in the Assets section or Any Category in the Taxonomies section are the default permissions for that user or group. You can override those permissions with the permissions specified for selected asset types and selected categories.
Parent and Child Category Granular Permissions
The permissions you apply to a category also apply to all its child categories. You can expand the permission granted on a parent category in a child category, but you can't restrict the permission granted on a parent category in a child category. For example, if you grant View access to the parent category "Product Line 1", you can grant View access to the child category "Product A" and add Categorize access; but if you grant View and Categorize access to "Product Line 1", you can't remove the Categorize access to "Product A".
User and Group Granular Permissions
If a user is given refined access as both as an individual user and as part of a group, the user is granted cumulative access to all assets specified in those permissions. If different levels of access are granted to the individual user and the user as part of a group, the user gets the highest level of access available to them.
Granular Permissions Needed for Tasks
Here are some common tasks and the granular permissions needed to perform them:
- To see an asset, the asset needs to be uncategorized, or you need View permission on at least one category that asset has been assigned to.
- To add a referenced asset to another asset, you need Update permission on the parent asset and View permission on the child asset.
- When viewing an asset with referenced items, you need View permission on the parent asset to see the parent asset, and, if you want to see the referenced items, you also need View permission on the referenced assets, otherwise you'll just see "Insufficient permissions".
- To add an asset to a category, you need Update permission on the asset type and Categorize permission on the category.
- To create a site, you need Create Site permission on the parent category (any non-site category) in a site security taxonomy.
Use Case Example for Taxonomy Category Granular Permissions
The following is an example of how granular permissions are applied based on the following taxonomy.

Assets in the repository are categorized as follows:
- Item1 is added to CAT1
- Item2 is added to CAT2 and CAT4
- Item3 is added to CAT4
- Item4 is added to CAT1.1.1
- Item5 is added to CAT1 and CAT1.1.1
- Item6 is added to CAT1 and CAT2
- Item7 is added to CAT1.1.1 and CAT3
- Item8 is added to CAT3 and CAT4
The following table shows examples of how different permissions would affect access to particular assets in the repository.
Selected Permissions | Access Granted in the Repository |
---|---|
![]() |
Repository members with this permission set:
Note: This permission set is granted by the Contributor or Manager role. |
![]() |
Repository members with this permission set:
|
![]() |
Repository members with this permission set:
Specifically, for a repository member with this permission set:
|
![]() |
Repository members with this permission set:
Specifically, for a repository member with this permission set:
|