User permissions for tags
User permissions for tags in Adobe Experience Platform are assigned to users through Adobe Admin Console. Rather than being assigned to individual users, different sets of permissions are configured separately as product profiles. Users are then assigned to these product profiles in order to be granted the permissions they’ve been configured for.
This guide provides an overview of the different types of permissions available for tags, the functionalities they grant access to, how to configure them in Admin Console, and some basic implementation strategies for different business use cases.
Prerequisites prerequisites
To configure permissions for tags, you must have administrator privileges for an organization that has a product integration with Adobe Experience Platform Data Collection. The minimum role that can grant or withdraw permissions is a product profile administrator. Product administrators can manage all profiles within a product, and system administrators have no restrictions. See the article on administrative roles in the Adobe Enterprise administration guide for more information.
This guide assumes you are familiar with basic Admin Console concepts like product profiles and how they grant product permissions to individual users and groups. For more information, see the Admin Console user guide.
Permission types
Within a product profile, permissions for tags are divided into four categories:
- Platforms
- Properties
- Property Rights
- Company Rights
Platforms
Each tag property has a platform. There are currently three platforms: Web, Mobile, and Edge. Edge properties are used for event forwarding. You can use this permission type to restrict or grant access to a particular type of property. This can be useful when the team that manages your mobile apps is different from the one that manages your websites.
Platform permissions only grant access when combined with other property rights.
Properties
By default, product profiles grant access to all properties that exist within your company, both currently and in the future. Using this permission type, you can restrict or grant access to specific existing properties by name.
Property rights property-rights
Any tag property that you create in the UI becomes available in Admin Console, allowing you to group the property with specific property rights in the same product profile.
For example, if a given product profile does not have access to Property A1, users who belong to that profile cannot see or modify any settings within Property A1.
If a user belongs to a profile that does have access to Property A1, the actions they can perform within Property A1 are determined by the rights they have been granted from this profile. If a user has permissions for Property A1 but has no assigned rights, then they have read-only access for that property.
The following table outlines the available property rights and the functionalities they grant access to:
This allows you to perform the following actions:
- Create rules and data elements
- Create libraries and build them in existing development environments
- Submit a library for approval
Most day-to-day tasks in the UI require this right.
This allows you to perform the following actions:
- Install new extensions to a property
- Modify the configuration for an already installed extension
- Delete an extension
See the extensions overview documentation for more information on extensions. This role typically belongs to IT or Marketing, depending on your organization.
Company rights
Company rights apply to permissions that span multiple properties. These are outlined in the table below:
This allows you to perform the following actions for web, mobile, and edge (event forwarding) properties:
- Create new properties
- Modify metadata and settings at the property level
- Delete properties
Administrators usually perform this role. See the properties documentation for more information.
Total user permissions
An individual user’s total permissions are determined by their total membership in different product profiles. If a user belongs to multiple product profiles, the permissions from each profile are added together rather than multiplied.
For example, Product Profile A grants you the Develop right for Property 1. Product Profile B grants you the Publish right for Property 2. In this case, you can Develop in Property 1 and Publish in Property 2, but you cannot publish in Property 1 or Develop in Property 2 because you have not been granted explicit rights to do so.
Rights scenarios
Different companies have different needs when creating new product profiles. These needs vary based on company size, organization structure, the number of sites, the number of people involved in managing tags, and so on.
Below are a few common scenarios and a recommended starting point as you think about creating product profiles and adding users to them.
One-person show
If you run a small company that has one person in charge of everything, grant this user permissions for all properties and assign them all rights listed above.
Separation of duties
Consider a situation where many people in your organization are involved in tagging. You have one set of people (such as an external consultant) that creates rules and data elements, but you do not want them to have access to the production environment. In this case, you want to make sure that nobody deploys to Production except the IT team.
To accomplish this:
- Create an account for your consultants and grant them only the Develop right.
- The consultant builds and tests within the confines you set.
- If the consultant wants a new extension or is ready to go live, a representative from your organization (with the appropriate rights) performs those actions.
Enterprise
An enterprise company might have multiple sites divided geographically, with different teams responsible for each geo. Within those teams, different individuals develop and publish.
This is similar to “Separation of duties” above, but organized by geographic areas. For example, you can create a “Develop” profile and a “Publish” profile for North America, and create separate “Develop” and “Publish” groups for Europe.
Example roles
The following table provides some examples of the types of roles you might have in your organization and which permissions you should assign them:
- Develop
- Manage Extensions
- Manage Properties
- Develop
- Manage Extensions
-
Manage Properties
-
Manage App Configurations
- Approve
- Publish
- Manage Environments
- Develop
- Manage Properties
- Develop Extensions
- Develop
- Approve
- Publish
- Manage Extensions
- Manage Environments
- Manage Properties
Configure permissions in Admin Console admin-console
Permissions for tags and event forwarding are managed under the Adobe Experience Platform Data Collection product in Admin Console. To configure them:
- Sign in to Admin Console, select Products in the top navigation, and then select Adobe Experience Platform Data Collection.
- Select an existing product profile, such as the default Default Data Collection All Access profile, or select New Profile to create one. If different roles or user groups in your organization require different levels of access, create a separate product profile for each of them.
- On the Permissions tab, select the edit icon for a permission category. Select permissions to move them between the available and included columns, switch categories from the left navigation as needed, and then select Save.
- Select the Users tab, and then select Add user to assign users to the product profile.
For more information, see the Admin Console documentation on managing product profiles.
Experience Platform permissions for data collection platform-permissions
Datastreams, schemas, and identity namespaces are not controlled by the Adobe Experience Platform Data Collection product profile. Instead, they are managed through Experience Platform access control. To work with these features, a user’s role must include the relevant permissions in the following categories, along with access to the appropriate sandboxes:
- Data Collection: Manage or view datastreams.
- Data Modeling: Manage or view Experience Data Model (XDM) schemas.
- Identity Management: Manage or view identity namespaces.
See the resource permissions reference for a full list of Experience Platform permissions, and the guide on managing permissions for a role for configuration steps.
Next steps
This document provided an overview of the available permissions for tags and event forwarding, and how to configure them in Admin Console. For more information on managing permissions for other Experience Platform capabilities, see the access control overview.