Product Profiles and User Groups

27 Jul 2020 » Admin Console

A long time ago I wrote about the Admin Console and I left some topics for a later post. The most important of these topics is related to how you provide different permissions to different users. This is what product profiles and user groups are for.

I do not think I need to explain why you would need to provide different levels of permissions to different users. What I will do instead is tell you a real life story of what happens when you do not take this seriously.

Many years ago, I was working for an Irish client as their Analytics consultant. One day, I received an urgent call from this client, stating that “DTM has broken our website”. That is a very strong statement, so I rushed to Dublin to fix the issue. The first thing I learned is that the problem was not that big. They had not published anything and the broken website was in the preproduction environment. Upon close inspection, the issue was with an intern, with no JavaScript knowledge, who had published a random piece of code he found through Google. The next thing that happened was that he lost the permission to publish, so that someone else could review his code.

Product profiles

As with any complex, multi-user tool, the Adobe Experience Cloud solutions can do many things and not everybody should be allowed to do them all. In fact, there is a security theory that states that you should only provide the minimum set of permissions needed to a user to perform his/her tasks.

In the case of Adobe, you achieve it through product profiles. You can create as many as you want and each will have a different set of permissions. What do I mean by “set of permissions”? It depends on the tool and I will get into the details of each Adobe tool in future posts.

A simple way of understanding a product profile is to associate it with a role. For each role in your organisation, you could create a product profile.

Examples of product profiles

It is usually easier to understand a concept through examples. I will use Adobe Analytics to show the concept of product profile and I will use the association with roles.

  • Marketing director. This person will want to get the reports of the production report suites, but will never create new report suites, configure them or be interested in development report suites. In fact, it is better to prevent him/her doing anything other than access the reports or you will regret it.
  • Web analyst. This role will likely need access to all the features of Adobe Analytics and all the report suites.
  • Web developer. Developers will also need access to most of the features, but you do not want them to see production data, so you limit the list of allowed report suites to those used in the development environment.
  • QA. Similarly to the web developer, you will want to limit to the QA report suite, while providing access to the Analytics tools to evaluate the tests.
  • App analyst. If you have separate web and app analysts, it is usually the case that they will not want to know what the other is doing. So, although they should be given the same access to Analytics tools, the set of report suites may be different.
  • Regional analysts. Multi-national corporations tend to create multiple report suites, one per region. For obvious reasons, regional analysts should only see the data in their region.

Product and product profile administrators

The admin console allows for decentralisation of the admin roles. Instead of having a single system admin who takes care of all the users, you can distribute the user management. For each product, there are two levels of administrators:

  • Product administrators. These users can add and remove users to/from any product profile within the product.
  • Product profile administrators. They are one level below, as they can only manage users for a specific product profile.

There is one clarification I have to make. These administrator roles are only limited to the user management. If you are looking for a user who should be able to do anything with a product, you first need to create a product profile and configure it with all permissions. Then, you assign this product profile to these super users. I know this can be confusing. In the past, an administrator was someone with god powers over the tool, both for configuring it and managing users. Now, these two type of roles have been separated.

User Groups

Strictly speaking, this feature is not really needed. It is there to make our life easier in case we need it. A user group is just a collection of product profiles. These product profiles can be from different products. This is useful if you have a requirement to assign multiple users to the same combination of product profiles. For example, if many users need to access some reports suites in Analytics and one workspace in Target. So, when adding users, instead of having to select multiple product profiles, you would just need to select a user group.

As with products and product profiles, you can assign user group administrators. These administrators are exactly like those I have mentioned above: they can manage users of this user group.

Adding users

The Adobe Admin Console offers multiple ways to add new users. One such way is to go to the product profile or user group that you are interested in and select the “Users” tab. You will see there is an “Add User” button, which opens a very simple form to add users.

You can also add a user from at product level. After selecting the product, there is also a “Users” tab. If you try to add a new user from there, you will need to select the product profile before you can save.


Photo by Alex Kotliarskyi on Unsplash

Related Posts