Manager Hierarchy Model: Part 1

Hey there, good people! Welcome back to my Power Platform Security blog. Today we’re talking about the Manager Hierarchy Model. Let’s have some fun.

What are Hierarchy Models?

Well, we’ve discussed how we can create security roles with various privileges and assign these roles to users and teams. We’ve also covered the concept of record ownership and how it works alongside security roles. But say we have an environment that requires additional privileges that may just overcomplicate the need for security roles, an environment where users own records and roles define access privileges, but now there is a need to implement manager access and job title access. Imagine having to create a security role per manager type or a security role per position. It would be an admin nightmare to maintain them. That’s where the Hierarchy Models comes in. A simple method of granting privileges in line with an organigram on top of security roles.

The Manager Hierarchy Model

It’s in the name, right? You know how in Entra ID or Office 365 Admin, we can assign managers to users, and it makes up a pretty organisational chart in Team?

We can do the exact same thing within a Power Platform environment. When it comes to managing access and other user-specific information regarding an environment, this data is stored within the User table (systemuser). Using the User table, we can relate and associate security roles with a user, define their business unit, and assign them a manager.

You can also assign a manager to a user from the Power Platform Admin Center. Simply navigate to the environment to which you wish to assign a user’s manager (we’ll get into why it’s environment specifically in Part 2) and select Users > the user you want to edit > Change Manager.

You can also do this through the classic portal by going to Settings > Users > Manager.

(P.S. I especially left that top banner open about the deprecation.)

Now we’ve just started a journey into the Manager Hierarchy Model. While we discuss it in this post, you will see references to the Position Hierarchy Model as well. This model follows a similar concept but needs a bit more configuration. However, this is a post for another time.

Understanding the Concept

A few posts back, we looked at security roles and how a sales team would potentially own their own sales records. If you missed it, be sure to read it here. Let’s use the same concept but adjust it slightly for this case. We have a role called Avengers. The role will be assigned to all members of the Avengers team. However, the role ensures that all Avengers can see threats but can only use their own weapons (gosh, imagine Tony using Thor’s hammer).

If Thor were to get a new hammer, we could add it to his inventory, and it would belong to him. No one should be able to interact with it. But because Thor reports directly to Steve, Steve will have access to the records Thor owns and records that a group owns that Thor is a part of. Additionally, if we configure the model to go further up the hierarchy, we can then ensure that Nick, who manages Steve, can also see Thor’s record but not edit it unless he has another role allowing him to edit user-owned records. If Peter, who reports to Tony, decides to share a record with Thor, Steve would only have read privileges to that shared record. Make sense?

So, by enabling this type of model, we can ensure that our core security role is performing its function by locking down record privileges to a user level, but the hierarchy model grants managers access to their direct reporting staff, mitigating the need to build multiple manager-specific roles.

Setting Up the Model

Having your hierarchy defined per user is very important, and if you are enabling this model in an environment with existing users, I’d highly recommend you ensure your organisation hierarchy is configured in the environment before enabling this feature. Once you turn this feature on, you can still easily maintain your hierarchy, both through the model and using the User table, but it’s probably also a really good idea to have a process defined as to how and when you assign managers to new users entering the environment.

If we head over to the Admin Center again, select our environment, and go to Settings > Users + Permissions > Hierarchy Security, you should be navigated to the model configuration page.

Let’s elaborate more on what we’re actually setting up:

1. Disable hierarchy modeling: Obviously, if selected, there is no hierarchy enabled within the selected environment.
2. Enable Manager Hierarchy Model: Select this to enable the manager model, and when you click on configure, you will be redirected to a list of users you can configure for the model. When you select a user, you’re basically interacting with a form on the User table.
3. Enable Position Hierarchy Model: Select this to enable the position model, and when you click on configure, you will be redirected to a list of positions you may already have in the environment. You can also create new positions and start building up an organisational chart defining where positions sit in the hierarchy. You can then assign these positions to users in the User table.
4. Depth: The depth figure defines how far down the hierarchy you are enabling access. So, using our above example, if Thor owns his record, a depth of 1 will ensure that Steve can see that record. A depth of 2 will allow Nick to view Thor’s record as well.
5. Hierarchy Table Management: This section allows you to also specify what tables you want the model to be applied to.

If you go to the configuration page, you can interact with user records as you would through the User table form. You can assign managers as required and start expanding your hierarchy. If a hierarchy exists for a user, a little hierarchy icon will appear next to their name in the user list. If you select the icon, you should be presented with a Power Platform version of the environment’s organisational chart.

Part 2

After reading this post, I can imagine what comes to mind. Why not just use the user manager from Entra ID? It saves the trouble of having data in two places. You are absolutely right, and unfortunately, I only have some of the answers. So, in the next part of this blog, we’re going to explore some of the limitations within the hierarchy model, methods on how to overcome some of these challenges, and some weird UI experiences between Dynamics 365 and Power Platform.

In the meantime, I hope you enjoyed this post.