To work in Launch, there are two user permissions to understand:
Experience Cloud Permissions: Found in the Admin Console at the company level, Experience Cloud permissions govern who can control group permissions and group membership for all Experience Cloud products.
Launch Permissions: The permissions for Launch, one of the Experience Cloud products, are found in the Admin Console at the Product Profile level. Launch permissions govern which users can actually perform certain actions when logged into Launch.
This article examines these different permissions types in detail.
This section discusses factors that are important to understand when using Launch. See Administrative Roles in the Enterprise User Guide for a comprehensive view of Experience Cloud permissions.
Organization Administrators are often referred to as Org Admins. An Org Admin's main function is to assign permissions to other users. They do this by creating Product Profiles (or groups) that contain a specific set of rights within a specific product and then assigning users, existing or new, to that Product Profile.
Enterprise Org Admins do not inherit any rights in Launch. They must add themselves to a Product Profile that has Launch rights if they want to do anything in Launch.
A Product Administrator (or Product Admin) is similar to an Org Admin, but is narrower in scope. A Product Admin only has the permission to modify Product Profiles for a specific Adobe product, rather than all Adobe products the company has access to.
Within the Experience Cloud, no rights or permissions are assigned to individual users. They are assigned to a Product Profile (see Experience Cloud Permissions above). Individual users are then assigned to one or more Product Profile.
Within a Product Profile, Launch permissions are divided into two categories, property rights and company rights.
Any properties you create in Launch become available in the Admin Console for you to assign permissions. 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.
Assuming that a user belongs to a profile with access to Property A1, what they can do within Property A1 is determined by the rights they have been granted. Users with permissions to Property A1, but no assigned rights, have read-only access.
You can set the following property rights:
Develop: Grants the ability to create rules and data elements. You can also create libraries and build them in existing development environments. You can submit a library for approval when ready. Most day-to-day tasks in Launch require this right.
Approve: Grants the ability to take a submitted library and build to the staging environment. You can also approve a library for publishing once testing has been completed.
Publish: Grants the ability to publish approved libraries to the production environment.
Manage Extensions: Grants the abilities to install new extensions to a property, to modify the extension configuration for an already installed extension, and to delete an extension. More information on extensions is available here. This role typically belongs to IT or Marketing, depending on your organization.
Manage Environments: Grants the ability to create and modify environments. Read more about Environments here. This role typically belongs to the IT group.
Company rights apply to permissions that span multiple properties. There are currently two:
Manage Properties: Grants the ability to create new properties in Launch and to modify the metadata and settings at the property level. You can also delete properties. Read more about properties here. Administrators usually perform this role.
Develop Extensions: Grants the ability to create and modify extension packages that are owned by the Company including private releases and requests for public release.
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 Henry the Develop right for Property 1. Product Profile B grants Henry the Publish right for Property 2. Henry can Develop in Property 1 and Publish in Property 2, but he cannot Publish in Property 1 or Develop in Property 2 because he has not been granted explicit rights to do so.
Different companies have different needs when creating new Product Profiles. These needs vary based on company size, org structure, number of sites, 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.
If you run a small company that has one person in charge of everything, grant this user permission to all Properties and assign them all rights listed above.
Many people are involved in tagging. You have one set of people (maybe an external consultant) that creates rules and data elements, but you don't want them to have access to the production environment. You want to make sure that nobody deploys to Production except the IT team.
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.
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.
A few examples of the types of roles you might have in your organization, and which permissions you should assign them, could help to clarify this concept.
Here are a few descriptions of different roles that could apply in your organization and a matrix to show what permissions they need to do their job.
The Manager: Wants to see what's going on, but shouldn't be able to make any changes.
The Marketer: Can install extensions and setup new tags for existing properties, but cannot publish to the staging or production environments.
The Mobile App Developer: Is responsible for implementing Adobe and 3rd party solutions inside a native mobile app.
The IT Team: Doesn't actually modify any tags, but they have full control over the staging and production environments and what is in them.
Jack of All Trades: Does everything.
Develop Manage Extensions
The Mobile App Developer
Develop Manage Extensions
The IT Team
The Jack of All Trades
The Extension Developer
The steps below guide you through the process of assigning permissions. You can also view this process on video.
Steps 1-3 below can be bypassed by navigating directly to Adobe Admin Console. If you belong to more than one organization, select the correct org from the top nav on the right.
Sign in to https://experiencecloud.adobe.com/ with your Adobe ID, then choose the organization to use within Launch from the Navigation menu.
Open the solution picker by clicking the 9-dots icon from the navigation menu, then click Administration.
If you can't see this link, both of the following conditions are true:
You are not an org admin.
You are not a product admin for any Experience Cloud products.
In either case, ask an org admin to perform these steps for you, or to make you a product admin for Launch so you can do it yourself.
Note: If you don't know who your org admin is, contact Client Care.
Click Launch Admin Console.
Click the Launch, by Adobe - %Company Name% card.
You can also click Products in the top nav, then select Launch, by Adobe - %Company Name% from the left nav.
If you do not see a Launch, by Adobe card and or if Launch, by Adobe does not appear in this list, then you are not an Org Admin, but you are a Product Admin for other Experience Cloud products. Because you are not an Administrator for Launch, you need to find an Org Admin who can perform these steps for you or who can make you a Product Admin for Launch.
After you select Launch, a list of product profiles displays. Think of these profiles as permission groups. One profile is created for you and is named Launch - %Company Name%.
If you are editing an existing product profile, skip this step.
Choose to edit this product profile, or create a new one.
To create a new product profile, click New Profile.
Give your new profile a name and a description, configure whether users should receive emails when they are added or removed from this profile, and then click Done.
Select the product profile from the list, then open the Permissions tab. You can assign permissions across two dimensions: Properties and Rights.
To assign properties to this group definition, open the Properties section.
A list shows your Launch properties.
By default, new product configurations automatically include properties. This means that all properties (present and future) are included in the group definition.
If Auto-include is disabled, all currently available properties are listed on the left. You can move properties into this group definition by clicking Add.
Click Save when finished.
Assign the rights you want to be part of your group definition. Open the Rights section.
Rights are not automatically included. You must assign each right to your profile. You can quickly add all rights to this profile by using the + Add All button or you can assign individual rights by using the individual + buttons. For more information on what permissions are associated with each right, see Rights details. Click Save when finished. If Save is not available, you didn't make any changes and the profile won't give you any rights.
First, assign Property Rights:
Then, assign Company Rights.
Some important notes:
Lack of rights means read-only access.
If you belong to a product configuration with Auto-include properties and no rights, then you have read-only access to all properties in Launch.
If you don't at least assign the Manage Properties right, you won't be able to add any properties when you log in.
A user can belong to multiple groups, but the rights from those groups are not combined into a master permission set. That user still has only the rights explicitly granted by each group.
For example, if Group 1 gives access to Property A with the Develop right and Group 2 gives access to Property B with the Publish right, Develop and Publish rights are not combined for Property A and Property B. You can only develop on Property A and publish on Property B.
To assign users to be part of your group, open the Users tab, then click Add User.
Click ... for additional options, such as bulk user operations.
Note: Being an Org Admin or a Product Admin does not grant you any rights within the Launch product. You must belong to at least one product profile.
Search for the user you'd like to add to the group. You can search by name or by email address. This auto-populates from existing users in your Org. Once you have found the user you want, click on their name.
Once you've added users, they receive an email letting them know that they now have rights to Launch. They can login to Launch at https://launch.adobe.com.
Note: If the user does not exist, you can simply type their entire email address, then provide a first and last name. The new user receives an email, and when they create an Adobe ID from that email invitation, they are linked together with the user account you created for them. If you are assigning permissions for yourself, you won't have this issue.
When you log in to launch, you receive a message saying "Error Loading Account".
Resolution: Your user does not belong to any Launch product profiles. See the steps above to create a profile and assign rights to it, and to assign a user to a profile.
Once you've logged in, you can't add any properties.
Resolution: Your user account does not belong to a product configuration that has the Manage Properties right. Go back to Step 5 above.