Position Hierarchy Model: Another Way Forward

Hey there, good people! Welcome back to my Power Platform Security blog. Things have taken a slight turn. I’ve recently adopted an Avengers theme approach to my Security blog series (something exciting is on its way so I wanted to align the theme to my blog), so going forward, you’ll be seeing a lot more references and theming around The Avengers. Maybe if I brush up on my Star Wars, the next series can be themed around that. For now, welcome to the Power Platform Avengers: The Infinity Stones of Security:

What are Hierarchy Models

Previously, we explained what Hierarchy Models are, and we explored the Manager Hierarchy Model. Just as a quick refresher, the hierarchy models are an additional layer of security that can be applied alongside security roles. The models allow you to apply further hierarchical privileges to records that security roles cannot. For example, a security role can ensure that users can view records within their business unit. In some cases, this still may be too much access, but locking the privilege down to a user read-only privilege prevents anyone else from accessing that record unless it’s shared.

The hierarchy models allow for a hierarchical view of that data. So, with a user-owned record, if a manager or specific position needed access to that record, the hierarchy model would work great.

The Position Hierarchy Model

Similar to the Manager Hierarchy Model, the Position Hierarchy Model defines an organisational chart based on role positions. Keep in mind again, just like managers need to be configured in the User table within an environment, the same applies for positions. They do not sync with Entra ID.

So let’s look at our position hierarchy organisational chart. Below, we can see that Nick Fury represents S.H.I.E.L.D, the core organisation that oversees all the Marvel superheroes. Directly under Nick, we have Tony, Steve, and Peter leading their teams. We will also have Thor and Dr. Strange heading their own teams as well. No putting aside business units for a second; there’s a clear hierarchical flow to the MCU heroes. In most cases, the heroes work together, but the reason for the split is for times when a team needs to be assembled on their own.

Considering the above organisational chart, we can see that despite having a team called the Avengers, we still have two different Avenger Captains. This role reports directly to the S.H.I.E.L.D Director role.

Similar to the Manager Hierarchy Model, if we select Tony and view his User details, we can see that his manager is Nick and his position is set to Avengers Captain. We also have Steve, who would be assigned to this position; Peter Quill, assigned to the Guardian of the Galaxy Caption; and Dr. Strange as the Sorcerer Supreme.

Below each captain or leader, we would have the individual Avengers team members assigned to a sub position. For an Avenger such as the Hulk, he would be assigned the position of Avenger. Wong would be assigned the position of Sorcerer. This now creates a role-based hierarchy alongside the manager hierarchy. If I head now to the Avenger Captain position, I should be able to see all the child Avenger users, despite them having various managers or captains.

Our position Hierarchy is starting to look something like this:

Understanding the Concept

Now that we’ve discussed what our hierarchy model looks like, let’s look at how it works.

We have a security role that allows our heroes to be assigned to threats and fight with their weapons. In order to do that, we need a security role to define what privileges they have within the S.H.I.E.L.D Playbook solution. All heroes will be assigned the hero security role as displayed below.

The above role basically defines that a hero cannot just add another hero to the Avenger database. They can freely add new weapons that they use, and they can even share the weapons with other heroes in their realm. More importantly, all heroes can see the threats across the entire MCU but can only defend against threats within their realm (business unit). Lastly, because there’s always a rush to defend the universe against threats, all heroes tend to “borrow” each other’s ships.

If we were to implement the Position Hierarchy Model, this would mean that both Tony and Steve, who are Avengers Captains, could potentially access the weapons for the Avengers heroes that fall under them. This means that if James Rhodes were to get a new War Machine suit given to him by Tony, because James’s position reports the Avenger Captain position and Steve holds that hierarchy, Steve could yield the new War Machine suite. Nick, however, would only have access to look at the suit. 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 higher direct positions access to their directly positioned users, mitigating the need to build multiple position-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. 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.
2. Depth: The depth figure defines how far down the hierarchy you are enabling access. So using our above example, if James owns his record, a depth of 1 will ensure that Tony and Steve can see that record. A depth of 2 will allow Nick to view James’s record as well.
3. Hierarchy Table Management: This section allows you to also specify what tables you want the model to be applied to.
4. Configure: Unlike the Manager Hierarchy model, a bit more configuration is required for positions. When you click on configure, you will be redirected to a page of positions.
5. Add New: This is a basic table form, so all you need to do is click on “New” to add a new position.
6. Parent Position: Lastly, you can define your position hierarchy here. If a position has a parent position, lookup the value. Otherwise leave it blank and that position becomes a parent position.

If you go select “View Hierarchy” within a position, you will be able to view what your position hierarchy now looks like. It should look a little something like this:

Hierarchy Models Closing Remarks

Both the hierarchy models offer great additional security layers on top of an RBACs model you may already have. Streamlining privileges based on hierarchy on top of existing roles mitigates the need to implement complex security roles per manager or position. It helps simplify your security.

Although the hierarchy models offer a lot of additional security capabilities, there are times when they are limited. With modernised business units making their way into environments, the hierarchy models do not allow for hierarchy relationships to occur across child business units. A hierarchy relationship can exist between a parent and child business unit, such as Nick in the business unit MCU being the manager of Tony in the Midgard business unit. But Tony in the Midgard business unit cannot be a manager for a member in the Asgard business unit.

Lastly, it comes down to what your environment requires. You cannot enable the two hierarchy models to work in parallel. It’s either or. So when it comes to planning a solution design, having a clear vision of which model meets your business requirements will make security configuration that much easier.