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 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 Checkmark Checkmark Checkmark
Submit assets for review in workflow Checkmark Checkmark Checkmark
Move assets through workflow

* You need at least Viewer access to the repository, plus any required workflow role.


Checkmark
*

Checkmark
*

Checkmark
*
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.

 
Checkmark
*

Checkmark
*
Edit assets (including associating categories, tags, collections, properties, uploading new versions of digital assets, and, for digital asset repositories, channels)   Checkmark Checkmark
Delete assets   Checkmark Checkmark
Change repository membership, roles, and granular permissions     Checkmark
Edit the repository (including associating asset types, taxonomies, languages, content connectors, workflows, and, for digital asset repositories, publishing channels, and translation connectors)     Checkmark
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


Checkmark
*

Checkmark
*

Checkmark
*

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 10 taxonomy category rules.

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.

Use Case Example for Taxonomy Category Granular Permissions

The following is an example of how granular permissions are applied based on the following taxonomy.

Sample taxonomy described in text

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
View and Categorize selected for Any Category Repository members with this permission set:
  • Can view any categorized asset and add assets to any category in any taxonomy assigned to the repository (default rule applied to Any Category).
  • Can view non-categorized assets.

Note: This permission set is granted by the Contributor or Manager role.

Nothing selected for Any Category Repository members with this permission set:
  • Can't view any categorized asset or add assets to any category in any taxonomy assigned to repository (default rule applied to Any Category).
  • Can view non-categorized assets.
Nothing for Any Category, View and Categorize for CAT1, View for CAT2 and CAT3 Repository members with this permission set:
  • Can view assets categorized with "CAT1" or its children "CAT1.1", "CAT1.1.1", and so on and add assets to these categories (explicit rule #1).
  • Can view assets categorized with "CAT2" (explicit rule #2) or "CAT3" (explicit rule #3).
  • Can't view assets categorized with other categories (default rule applied to Any Category).

Specifically, for a repository member with this permission set:

  • Item1 is viewable (explicit rule #1)
  • Item2 is viewable (explicit rule #2)
  • Item3 is non-viewable (default rule applied to Any Category)
View for Any Category, nothing for CAT1, View for CAT1.1.1, View and Categorize for CAT2, nothing for CAT3 Repository members with this permission set:
  • Can't view assets categorized with "CAT1" (explicit rule #1).
  • Can view assets categorized with "CAT1.1.1" which is a child of "CAT1" (explicit rule #2).
  • Can view assets categorized with "CAT2" and add assets to this category (explicit rule #3).
  • Can't view assets categorized with "CAT3" (explicit rule #4).
  • Can view assets categorized with other categories (default rule applied to Any Category).

Specifically, for a repository member with this permission set:

  • Item1 is non-viewable (explicit rule #1)
  • Item2 is viewable (default rule applied to Any Category)
  • Item3 is viewable (default rule applied to Any Category)
  • Item4 is viewable (explicit rule #2)
  • Item5 is viewable (explicit rule #2)
  • Item6 is non-viewable (explicit rule #1)
  • Item7 is non-viewable (explicit rule #4)
  • Item8 is non-viewable (explicit rule #4)