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

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: 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.
	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.
	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)
	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)