Build a Hierarchy tree in Power Apps​ based on Azure AD

What is a hierarchy tree?

I think this is obvious, but if I need to explain it, in this case, a hierarchy tree is information that helps you understand your level in a company hierarchy; who your manager is, and at what level your colleagues are. We can extend this understanding further by looking at a hierarchy tree from the top level; it helps us infer who is the main boss in a company, their subordinates, then their subordinates, and so on, to the ground level. 

You will see hierarchy trees in every single company. Maybe some companies are running without an adequately built hierarchy. Who knows?

I have built one hierarchy tree in Power Apps to show you how it works!

Why build it in Power Apps?

This is all about reducing costs and efficiency. Many people are trying out low code, and one of the low code platforms is Power Platform. Low code approach, in many cases reduces the effort needed to deliver an application and is simpler than regular programming. In Power Platform, you can create applications using Power Apps. 

In this article, I will show you how you can create a working hierarchy tree based on Azure AD, and we will build it in Power Apps Canvas Apps.

I just realized, I have already built it in Power Apps. Really? Yes! Grab a link to the ZIP file which contains exported Power Apps application. Link to the application ZIP File: Hierarchy tree app.

How is it helpful?

If you are here, you probably got lost, or you may need to build some hierarchy tree. It’s 50/50, I would say. Or you are just curious about what this article is about. Can’t really tell. Leave a comment below, then I’ll know!

If you are here to learn, I will answer this question. 

So, how is this helpful? Building a properly working hierarchy tree:

  • Helps you get information about all management if needed
  • Enables you to get the proper User to whom you should send an approval
  • Allows you to get your subordinates if you are the manager
  • Allows you to get your subordinates, subordinates if you are a Director (in my case Director manages Managers, who have subordinates, I hope this is clear)
  • You don’t get an error if you are CEO and you don’t have a manager
  • You don’t get an error if you don’t have subordinates
  • Allows you to manage permission within the application
  •  It enables you to filter records when a system determines on what level the current User is
  • And many more.

As you can see, many things can benefit from a properly built hierarchy tree. It is not just about approvals; a hierarchy tree can be used in many cases.

Proper hierarchy tree in Power Apps

Just a couple of notes.

I have built a working version of a hierarchy tree in Power Apps for a hierarchy tree of 4 levels max. What does that mean? It means, for example, that if you are on a ground level (you are a Developer) and you want to use the application for approvals, and you want to send an approval to the CEO, but in your company, your CEO is placed at 8th, top level, you will not be able to. You will need to customize the app. I would spend a week perfecting the app for every possible scenario, but I had to stop somewhere to make it work. You will not be able to automate much after importing it because the application shows how to build a hierarchy tree, and it doesn’t solve your business need. You will see.

You can import the app to your tenant and see if it works, and what is more important, try to understand and extend the capabilities. This app is supposed to give you an idea of how a hierarchy tree can be built and what Power FX functions and components I used. Link to the application ZIP File: Hierarchy tree app.

This is what my application looks like.

Not the prettiest, I know, I know. 

And this is what my testing playground looks like. This is a hierarchy tree based on Azure AD.

More teams are in this hierarchy tree, but it is not that important now.

What this application is capable of

Let’s have a closer look at the application’s features visible in a main screen. I will paste the screenshot once more, so it is easier for you to understand.

This application determines:

  • How many levels are there in a hierarchy
  • What is the level of a current user
    • Developer
    • Manager
    • Director
  • What is the Manager of a current user
  • What is the Director of a current user

This application also helps you get all your subordinates if you are the Manager of a Director. “My filtering dropdown would be”  stores information about your subordinates. Let’s assume you would use this hierarchy tree for approvals of timesheets. You see only your records if you are a Developer (ground level). If you are the Manager, you see timesheets of your subordinates; if you are a Director, you see timesheets of your subordinates (Managers at 1st level) and their subordinates. I will present you with an example.

In the screenshot from above, you can see that label “My filtering dropdown would be” lists only Adam Kowalski. Adam Kowalski is a Developer, and he sees his timesheets.

Now, how does it look for his Manager?

As you can see, “My filtering dropdown would be” now lists more records. If you check a hierarchy tree from above, you can see that Joni Sherman is a Manager, and she would see her timesheets and the timesheets of her subordinates.

For the Director, it looks like this:

You can see that the first dropdown contains more records than just Joni + her team because there is one more team placed in a hierarchy under Nestor, and it looks like this:

As for the last two dropdowns, they allow you to choose a person to whom you would send requests or approvals. The first stores your direct Manager, and the second one will enable you to get a Director to whom you would escalate a request.

Again, let’s see what it looks like for Adam Kowalski – the Developer.

Adam would send requests to Joni Sherman and escalate to Nestor Wilke if escalation was needed. As the hierarchy tree shows it:

You saw the application, and I hope you understand its limitations. Still, the general idea stays the same – allow Makers to build a proper hierarchy tree, focusing on the bottom level for business processes.

You probably noticed that I had developed this app in a way the Director cannot send requests – yes, or Manager can’t escalate – also, yes. Those are not the essential things in the app. I hope you understand.

Okay, we have checked what this application looks like and its capabilities. But how did I build it?

How is it built?

I will shortly describe the most important functions that allowed me to build it.

The hierarchy tree is based on the Azure AD hierarchy. Without proper Azure AD hierarchy, you could not do anything. You must have an adequate hierarchy tree built somewhere to know who is the Manager, Director, and so on. This is the most important thing.

These actions listed below helped me in the process of creation of a hierarchy tree:

  • Set – allows you to create variables
  • Collect – allows you to create collections
  • Office365Users.MyProfile – gets the current user profile
  • Office365Users.Manager – gets current user Manager
  • Office365Users.DirectReports – gets current user subordinates
  • IsBlankOrError – this function handles exceptions and helps avoid errors
  • IfError – helps you do something different if an error occurs, very similar to the IsBlankOrError function
  • ForAll – this function, while creating a collection based on another group, helps you get all records from a collection

Only these functions were used to create collections containing all the configurations required for this application to run smoothly.

All the configuration and code are stored in the mysteriously named “Load configuration” button. You need the “Office365Users” connector added to the application to make it work. Voila!

I will not paste the complete code of the configuration here because it’s a silly idea. You will need to go and import the application yourself to see precisely what the configuration looks like.

Once more, I am pasting a link to the application ZIP File: Hierarchy tree app.


A proper and working hierarchy tree is a must in every company. By building one within your organization, you can automate many business processes or manage permissions. My application for this article shows you how to approach this problem and what functions I have used to create a properly working hierarchy tree. Try it yourself and customize the application, add more things, and have fun with Power Apps!

So, finally, we are at this point where I should thank you for your time and reading this article. Feel free to rate this article and comment if you liked it. If you have any questions, feel free to contact me (via, but first, you may be interested in joining a Newsletter. Hmm? (Sign up here) If you already did, wow, thanks, thanks a lot 🙂 

Via Newsletter, I am sharing insights into my work, plans for upcoming weeks, and knowledge about Power Platform Universe and the IT world. If you are interested, feel free to join! I am going to send the latest Newsletter to everyone who enters!

See you!

About the author

Daniel Ciećkiewicz


I am a Senior Power Platform Consultant focused on Dataverse, Power Apps, and Power Automate. I was also a Team Leader responsible for the Power Platform Team and their development paths. 

In my private life, I like video games, sports, learning & gaining knowledge, and a taste of good Scotch Whisky! 

Ooo, I almost forgot, I love our Polish Tatra Mountains!

Top 3 articles
Newest articles
These May also interest you:
0 0 votes
Article Rating
Notify of

Newest Most Voted
Inline Feedbacks
View all comments

[…] Azure AD. I even shared an application I’ve built so you can check it out! The link is here: Build a Hierarchy tree in Power Apps based on Azure AD. You can download the app from […]


[…] Azure AD. I even shared an application I’ve built so you can check it out! The link is here: Build a Hierarchy tree in Power Apps based on Azure AD. You can download the app from […]

Would love your thoughts, please comment.x