Utilizing the AAD User table in an Approval Flow

Shows the Power Apps solution explorer where the table overview is highlighted. In it we highlight the AAD User as this is of the type Virtual.

You might have seen the new AAD User table appear in your environment. This table is available to us for a couple of months now. And you might wonder what it is and how you can use it. In this blog I will explain you what it is and how you can use this table to your benefit.

The AAD User table lists all users in your Azure Active Directory. It does not show AAD Groups. Did you know that the data of this table does not reside in your dataverse storage? It is actually a Virtual Table! Virtual Tables are tables that do not reside inside Dataverse, but instead reference a table from a different storage mechanism. It is incredibly powerful as it does not require you to copy data from another system. You can find if a table is virtual by looking at the type column of the table overview. So why is this interesting and what can you do with it?

Shows the Power Apps solution explorer where the table overview is highlighted. In it we highlight the AAD User as this is of the type Virtual.
AAD User Virtual Table

The user table does not contain all users in your organization

To appreciate the value the AAD user table brings we have to look at a simple scenario. If we are in the service department and we are working a case for a specific account, it could be that this account is a key account for an account manager. If we want to link that account manager to that account it might be that we cannot find that account manager inside our User table. Now why is that you might ask?

The User table only contains those users who possibly have access to apps inside the environment you are working in. Michael Roth wrote an excellent blog and cheat sheet for if a user cannot see an environment. The same logic applies here for the user table, although we can skip the Security Role aspect. If a user has a license and is part of the security group of the environment only then will that user be added to the user table.

a Cheat Sheet of when a user has access to an environment. Did you assign a license? Did you setup a security group for this environment? Is it with a database? Do you have a maker role?
How Users can see ‘that’ environment – From Michael Roth

I consider it to be a best practice for both governance, maintainability and security to assign a security group to an environment. This will make it easier to see who has access to an environment. Also a shorter list in the User table will make it easier to administer who needs which security role.

In comes the AAD User table

So this means that whenever you want to add someone as a subject owner to a certain table, you are better off to use the AAD table. We can search and select for every user in your Active Directory of your organization and add it to a record as a Lookup. You can do this of course also with a normal text field. And unfortunately using the AAD table in the Model-Driven app context we don’t see a lot of extra information of that user on the form.

Now what can we do with it? The first thing I thought of is of course use this in an Approval Flow! As you might know I have quite a list of blogs about using Approval Flows in the context of a Business Process Flow. I add the approver to the record and then use that information in an Approval Flow. Now that same concept we can apply for the AAD table / Lookup.

First add a Lookup column to the table you want to run the Approval Flow from. In my example it is the Case table.

Shows the creation of a column in Dataverse. The column is called Approver and it's of the data type Lookup. The related table is AAD User
Lookup to AAD User

If you follow the steps in this blog, instead of the User Lookup we fill in the AAD User Lookup.

Shows a Model-Driven app with a form. On the form is the new Approver AAD field. In this field Ben den Blanken is selected. It is visibly different by the icon and the generated name then the User table shown just above.
Case Form with Approval AAD

This AAD User Lookup now contains the Azure Active Directory UserId. We can use this Id inside the “Start and wait for an approval” directly. There is no need to lookup an email address first.

Shows the Start and wait for an approval action where the assigned to is highlighted. This attribute is filled with the AAD User Id which is selected.
Approval Action with AAD User Id

Wrapping things up

And that’s it! We are now ready to test the changes to our Approval Flow. In my opinion a perfect example of how you can use the AAD User table.

There are of course more examples where you can use this functionality. But because we do not have a lot of information available from within the Virtual Table itself, a good start will be the Power Automate Action: Get User Profile from the Office 365 Users connector. This will return for example the phone number and e-mail adress. Which you can then use for sending e-mail notifications. For a full list of available information (if entered in their profile of course) go to the docs here.

Shows a Power Automate action called Get User Profile (v2) of the connector Office 365 Users. Inside the User (UPN) attribute is filled with the Azure Active Directory Id of the selected user.
Get User Profile – Office 365 connector

I hope this helps explain what you can do with the Azure Active Directory User table and why it matters.

Leave a Reply

Your email address will not be published. Required fields are marked *