I am putting it out there now. It’s the first line of this post. This blog post was written based on a method I recently used. I’ll elaborate further on why I’m open to this post being shredded apart (and I’m hoping it is).
Catchup
In my previous post, Manager Hierarchy Model – Part 1, we discussed the concept behind the Manager Hierarchy model, reviewed how it worked in line with record owner, roles, and manager hierarchy, and even went over how to setup the model as well. In this post, things are getting a bit heated. Let’s call it a happy type of frustration.
As we know, Hierarchy Models are built using the User (systemuser) table within an environment. As you can expect, only users within that environment exist within that table, meaning that if 100 selected users out of 900 users in a tenant were added to an environment, only those 100 users would then exist in the User table. Now that we’re caught up, let’s cause some trouble.
Some Frustrations
This is where I want some input. When it comes to the Hierarchy Models, because the User table is separate from the Entra ID table, fields like the user manager and position do not align. Let’s use Peter as an example. In Office 365, Peter is clearly reporting to Tony.
But if we head over to our user table in our selected environment, Peter has no manager!
It’s frustrating, isn’t it? That means that whenever a new user is added to an environment, someone needs to configure their manager through a User form. In an environment with a handful of users, I think that’s ok. But when dealing with hundreds of users, it becomes an admin nightmare. More so, what if you are setting up the environment from scratch and you add all 900 users to the environment but need the Manager Hierarchy Model enabled? Are you really going to manually assign each user a manager? I didn’t think so.
The big question is, how do we align Entra ID managers with user managers in an environment? If I have missed something and there is a sync setting that allows you to sync Entra ID profile details to the related user record in an environment, do me a favor and stop reading this post and ping me on LinkedIn. This will be a waste of time. If you can’t share that magic with me, well, you’re not the only one.
I came across a similar question on the Community Forums (read about it here), and I eventually came up with a workaround. Let’s start at the beginning. A fresh, clean environment.
A Way Forward
I created a small manual flow that listed all records from the User table (I made sure to filter only those records that mattered and not the general service accounts). I then checked to see if a manager was already assigned to that user with a simple condition. If the user already had a manager assigned to them in the User table, great, we can skip them. If they didn’t, the flow continues.
If the manager field returns a null, I then retrieve the current user records manager from Office 365 using the Get Manager v2 action. Because the Azure AD Object ID exists in the user record, we can retrieve the manager from Entra ID. Once I got the manager, I called the same User table again, but this time I filtered the records to match the retrieved manager’s Azure AD Object ID. The reason why we have to retrieve the manager from the User table is because the Manager field is a lookup column to itself, and therefore we need the User ID value for that manager in order to update the user record.
I then composed the manager User ID (I’m tired and it was easier doing it this way to avoid the ‘Apply to Each’ showing up #DontJudge) and updated the user record in the User table. Remember, I’m updating the user we retrieved at the start, not the manager :). I only update the Manager (Users) field in this action, and I’ve been careful to use the tables schema set name wrapping the composed ID to ensure the lookup value is updated.
There you go. I managed to update all the managers in the user table very quickly.
Going forward, though, we also want to ensure that new users added to the environment also get their manager from Entra ID assigned to them. We can switch up the flow really quickly to be triggered when a user is added to a selected Entra ID group. We can then retrieve that user record from the User table, run the same validation, and update their manager.
Some Random Finds
When exploring the Hierarchy Models, there also seemed to be a weird mix-up between editing users in the Power Platform UI and the D365 UI. Let me explain.
If we go back to the Hierarchy setup in the environment settings page, we can either select ‘Configure’ next to the enabled Hierarchy Model and be redirected to configure the users. Or we can select to manage the security within D365.
When selecting the ‘Configure’ option, we are redirected to a user page where we can configure the users. It looks pretty standard, right? (P.S. I did not cut off the screenshot just above the ribbon. That’s where the page ended before my browser bookmarks. #PinkyPromise)
But if we choose to manage the security model through D365, we first land on a really basic look at the Hierarchy Model configuration page, but when we then select the ‘Configure’ option next to the model we choose, we get redirected to what looks like a more Power Apps-themed user configuration page than the previous one. I’m not too sure why they’re different, and they’re probably slightly mixed up. Weird one.
Conclusion
Anyway, I hope after reading this post you have a better understanding of how the Manager Hierarchy Model works, how to set it up, and how to overcome certain challenges. Again, if you know a way to auto-sync profile details between Entra ID and the Users table, give me a shout. I’m all ears. In my next post, we’re going to be looking at the Position Hierarchy Model.
I hope you enjoyed this post .
