To work in Adobe Experience Platform Launch, there are two user permissions to understand:
This article examines these different permissions types in detail.
This section discusses factors that are important to understand when using Platform 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 Platform Launch. They must add themselves to a Product Profile that has Platform Launch rights if they want to do anything in Platform 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 Profiles.
Within a Product Profile, Platform Launch permissions are divided across four dimensions.
Each property has a platform. There are currently two platforms that you can use in Platform Launch: Web and Mobile. 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 web sites.
This is a list of all Properties that exist within your company. You can use this permission type to restrict or grant access to specific existing properties (by name).
Any properties you create in Platform 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 from this permission group. Users with permissions to Property A1, but no assigned rights, have read-only access.
The permissions available within this group are:
Company rights apply to permissions that span multiple properties. There are currently two:
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.
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.
|Role||Properties||Company Rights||Property Rights|
|The Marketer||Auto-include||Manage Properties||Develop
|The Mobile App Developer||Auto-include||Manage Properties||Develop
|The IT Team||Auto-include||Approve
|The Jack of All Trades||Auto-include||Manage Properties||Develop
|The Extension Developer||Auto-include||Manage Properties
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 Platform 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:
In either case, ask an org admin to perform these steps for you, or to make you a product admin for Platform Launch so you can do it yourself.
If you don’t know who your org admin is, contact Client Care.
Click Platform Launch Admin Console.
Click the Experience Platform Launch -
Company Name card.
You can also click Products in the top nav, then select Experience Platform Launch -
Company Name from the left nav.
If you do not see a Experience Platform Launch card and or if Experience Platform Launch 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 Experience Platform Launch, you need to find an Org Admin who can perform these steps for you or who can make you a Product Admin for Platform Launch.
After you select Platform Launch, a list of product profiles displays. Think of these profiles as permission groups. One profile is created for you and is named “Platform Launch -
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 Platform 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 scenarios. 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 Platform 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.
Being an Org Admin or a Product Admin does not grant you any rights within the Platform 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 Platform Launch. They can login to Platform Launch at https://launch.adobe.com.
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 Platform Launch, you receive a message saying “Error Loading Account”.
Resolution: Your user does not belong to any Platform 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.