top of page

Building a Secure, Comprehensive User Profile System in Power Apps

Apr 2, 2025
2 min read
Illustration of a teal rose and connected data points flowing across a soft background

Showing the current user's name in a header is easy. Building an app that actually adapts to the person using it, their role, their permissions, and where they sit in the organization, takes a little more planning.

In this post I walk through a single named formula, for_CurrentUser, that pulls all of that together. It combines User() with Office 365 profile data, reads role membership from SharePoint groups, and gives every screen in the app one consistent place to ask: who is this, and what can they do?

Why one profile formula instead of variables

User() gives you the basics: name, email, and photo. Most real apps need more than that. They need to show different layouts for admins and members, display a person's manager or direct reports, enforce logic based on group membership, and show onboarding only once.

The common approach is to load each of those into a global variable when the app starts. That works, but the variables drift out of date, they cost memory, and every new screen has to remember to read them correctly. A named formula is evaluated when it is needed and is always current, so the rest of the app simply references it.

Step 1: Add the Office365Users connector

Add the Office365Users connector to your app, then open App > Formulas. Named formulas live there, and that is where the profile formula goes.

Step 2: Create for_CurrentUser

Paste the following into the Formulas pane. I keep it near the top so it is easy to find later.

Replace SharePointGroupsList with your own list, or with the result of a Power Automate flow that returns group membership securely.

Using it

Anywhere in the app, you can now reference the profile directly:

There are no repeated lookups and no variables to keep in sync. Every screen reads the same source.

Example 1: Send users to the right screen

Because roles are part of the profile, choosing each user's starting screen becomes one more formula:

Then navigate to it:

Example 2: Detect when onboarding is needed

The same profile can tell you when someone is new or missing information. Here, a user without a job title or office location is treated as needing onboarding:

Optional: Track onboarding in a SharePoint list

If onboarding should happen once and be remembered, record completion in a list and check it:

When the user finishes, save the result and send them on:

A nightly Power Automate flow can clear that flag when training expires, new materials are published, or a policy date passes, so people are prompted again when it actually matters.

Ultimately

One formula gives the app a complete picture of the person using it. It is reusable across screens, components, and conditions, and it is easier to secure and maintain than profile logic scattered across variables. The app uses less memory, the logic reads more clearly, and the experience adjusts to each user as they work.

In a future post I will show how to carry this formula across multiple apps using source control and automation.

If your Power Apps need role-aware access designed in from the start, see Nerdy Q's services.

Comments


bottom of page