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?
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.
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.
If you follow the steps in this blog, instead of the User Lookup we fill in the AAD User Lookup.
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.
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.
I hope this helps explain what you can do with the Azure Active Directory User table and why it matters.