When a Manager Isn’t an Attribute

One of the things I have run into when automating identity processes is that sometimes the information you need already exists, just not in the form you need it.

Identifying managers is a good example.

There are several identity processes where knowing who the managers are matters. When defining who should be in scope to request an Access Package, it can be easy to forget that the manager may need visibility of the package or need to request access on behalf of someone who reports to them.

The same applies to applications. In a SCIM-integrated application, manager can be a distinct persona with different access or provisioning requirements. In both cases, I need a reliable way of identifying managers.

Using jobTitle might seem like an easy solution, but I don’t particularly like relying on it. A manager doesn’t necessarily have “Manager” in their job title, and someone who does have it isn’t necessarily a manager for every process.

My first instinct was to look for something as simple as an isManager attribute I could query with Microsoft Graph.

But it isn’t there.

Entra knows the manager relationship, and Graph can give me a user’s manager or their directReports. What it doesn’t give me is a straightforward way to ask:

isManager = true

So the question became: how do I turn the organisational relationship that already exists in Entra into something the rest of my identity automation can actually use?

The information was already there

One option would be to add isManager to the HR-to-Entra integration.

If you own the integration and have the flexibility to change the mapping, that can actually be a good solution. We already know who the user’s manager is, so deriving the value as part of the integration makes perfect sense. But not every integration gives you that flexibility.
Many HR systems come with fairly predefined integrations. They are designed to work for many organisations, which is great, but it also means that adding one more piece of logic isn’t always as simple as adding a line of code.

The other option is to add another field in HR. And this is where I start feeling a little protective of our HR people. They already have enough to do without us coming along and saying:

“You know that manager you just entered for this employee? Could you also tick this other box to confirm that they are a manager?”

Especially when we can calculate it ourselves.

If the manager relationship already tells us who someone reports to, asking HR to maintain another value that can be derived from that relationship is just creating another opportunity for human error. And HR is already responsible for a lot of information that absolutely needs to be right. Salaries, employment details, organizational information and all the other things that make sure the rest of us get paid and have the right conditions. I would rather let them focus on that than give them another field to keep in sync because an identity process somewhere downstream needs it.

We have spent years trying to remove manual work from identity management because manual data creates errors. It doesn’t make much sense to remove manual work in Entra while adding more of it to HR. So if the HR integration can derive isManager from the manager relationship, great. But if it can’t, I don’t think we need to add another manual step to the HR process.

The relationship is already in Entra.

If we maintain the manager relationship correctly when users are provisioned, we can use that relationship to work out who the managers are ourselves.

Turning the relationship into something useful

The useful part is that we don’t have to treat the manager relationship as the final answer. directReports gives us the relationship, but we can apply our own rules to determine which relationships are relevant for the process we are trying to support. For example, we may want to exclude external users, administrative accounts or other identities that should not count when determining management responsibility.

That means the logic becomes less about simply asking:

Does this user have direct reports?

and more about:

Does this user have relevant direct reports according to the rules we have defined?

That distinction is important because the definition of a manager can be different depending on what we are trying to automate. The same approach can also give us more information than just true or false. Once we are evaluating the reporting relationships, we can derive other useful information from them, such as a management scope or other attributes relevant to the organisation.

This is where I see the value in turning the relationship into an identity signal.

The relationship already exists in Entra. The logic determines what that relationship means for our automation, and the result can then be written back as identity data that other processes can consume.

Putting the logic into a Logic App

I implemented this as a Logic App that runs once a day.

The basic idea is quite simple. It gets the users I want to evaluate, queries Microsoft Graph for their directReports, and then applies the filters that determine which direct reports should actually count for the calculation.

The Graph request itself is nothing particularly complicated. When testing the logic, I can also query the same endpoint directly with Invoke-MgGraphRequest:

Invoke-MgGraphRequest `
    -Method GET `
    -Uri "https://graph.microsoft.com/v1.0/users/$userId/directReports"

The important part is what happens with the response.

I don’t want every identity returned by Graph to influence the result. In my case, for example, administrative accounts and external identities should not make someone a manager just because they happen to appear in the reporting relationship.

So the Logic App filters the returned users before making the decision. Once the relevant direct reports have been identified, I can also derive the management scope I need for my particular use case. The Logic App then writes the result back to Entra as directory extension attributes. It also handles the other direction. If someone no longer has any relevant direct reports, the values are cleared or set back to false.

That makes the attributes a reflection of the current organisational structure rather than a value that was set once and then forgotten.

Making it useful

Once the information is available as directory data, the individual processes can use it for their own purposes. An Access Package can use isManager when defining who should have visibility or be able to request access on behalf of others.

A SCIM-integrated application can use it when manager is a separate persona with different access or provisioning requirements. And other identity processes can use the same signal without having to know anything about how it was calculated. That is what makes this more useful than simply having another value in the directory. I calculate the management relationship once, and then let the consuming processes decide what that means for them.

If someone becomes a manager, the relevant processes can react to that change. If they stop being a manager, the same processes can remove or change what was previously assigned. The organisational relationship becomes part of the identity lifecycle rather than something each application has to work out for itself.

From manager status to identity signals

I think this is actually a useful pattern beyond this particular example.

Identity systems contain a lot of relationships and information that isn’t necessarily available in the form that automation wants to consume. In this case, the source information is the reporting relationship. The useful automation signal is isManager.

The Logic App acts as the translation layer:

Manager relationship
        ↓
    directReports
        ↓
     Logic App
        ↓
 Business rules
        ↓
 Derived identity attributes
        ↓
 Identity automation
        ↓
Access / Teams / Applications

The advantage is that the downstream processes don’t have to care how the value was calculated.

They don’t need to know about directReports. They don’t need to query the HR system. They don’t need their own definition of what constitutes a manager. They can simply use the identity data that has already been derived for them.

If you want to see one way of putting this into practice, I’ve published a sanitized version of the Logic App I described here on GitHub. It’s built around my own rules and attribute names, so treat it as a starting point to adapt, not something to deploy as-is: EntraGovernance-Scripts/Logic Apps/Manager Flag Sync