365-anouck

How ToPower Apps

Show the Right Choices to the Right People: Role-Based Dropdown Filtering in Power Apps

Anouck 6 July 2026 5 min read
Show the Right Choices to the Right People: Role-Based Dropdown Filtering in Power Apps

Not every option in a dropdown should be available to everyone. Maybe one choice triggers a budget-heavy process, kicks off a formal approval, or represents a decision only a handful of people are allowed to make. In this post, I’ll show you two ways to handle this in a Power Apps canvas app driven by a SharePoint choice column — one that hides the option entirely, and one that catches it at the Next button — plus the governance caveat that matters more than either technique.

First: Knowing Who’s Allowed

Both approaches need the same starting point — a way to answer “is the current user on the allowed list?” The current user is always User().Email, and you’ve got three sensible places to keep the list of who’s permitted:

  1. Hardcoded in the app — fine if the list is tiny and rarely changes.
  2. A small SharePoint list — my preferred option, because you can update who’s allowed without republishing the app.
  3. A Microsoft 365 group — checked via the Office365Groups connector, if you’re already managing access that way.

I’ll use the hardcoded version in the examples below to keep the formulas readable. Swap in your own source once the logic makes sense.

Option 1: Filter the Option Out of the Dropdown

This is the cleaner user experience — if someone isn’t allowed to pick an option, they simply never see it. There’s nothing to correct after the fact, because the wrong choice was never on the menu.

Put this on the dropdown’s Items property:

If(
    Lower(User().Email) in ["alice@contoso.com", "bob@contoso.com"],
    Choices(YourList.YourColumn),
    Filter(Choices(YourList.YourColumn), Value <> "Restricted Option")
)

What does this do?

  • Lower(User().Email) in [...] → Checks whether the signed-in user is on the allowed list. I wrap the email in Lower() because user emails can come back with mixed casing, and a case mismatch would quietly lock out someone who should have access.
  • If allowed → return the full Choices() list, restricted option included.
  • If not allowed → return the list with the restricted value filtered out.

💡 Make sure "Restricted Option" matches the SharePoint choice value exactly — capitalisation, spacing, and punctuation all have to line up, or the filter silently does nothing. Copy the label straight from the column settings rather than typing it from memory.

Option 2: Catch It on the Next Button

Sometimes you want the option to stay visible — so people know it exists and understand it’s there for a reason — but you still need to stop the wrong person from proceeding with it. That’s where a check on the Next button comes in.

On the button’s OnSelect:

If(
    DataCardValue_Dropdown.Selected.Value = "Restricted Option"
    && !(Lower(User().Email) in ["alice@contoso.com", "bob@contoso.com"]),
    Notify(
        "You're not allowed to select this option. Please choose another.",
        NotificationType.Error
    ),
    Navigate(NextScreen, ScreenTransition.Fade)
)

What does this do?

  • They picked the restricted option AND they’re not on the allowed list → show an error message and don’t navigate.
  • Anything else → carry on to the next screen as normal.

Prefer to stop them before they even click? Grey the button out instead by putting this on its DisplayMode:

If(
    DataCardValue_Dropdown.Selected.Value = "Restricted Option"
    && !(Lower(User().Email) in ["alice@contoso.com", "bob@contoso.com"]),
    DisplayMode.Disabled,
    DisplayMode.Edit
)

💡 The Notify approach is friendlier when the rule needs explaining (“here’s why you can’t continue”). The disabled button is cleaner when the rule is obvious and you’d rather not let them get halfway there.

But Remember: This Is Client-Side Only

Here’s the part that’s easy to skip and important not to. Both of these techniques live inside the app. They shape what the user sees and what the interface allows — but they don’t enforce anything at the data layer.

A determined user could still write the restricted value another way: directly through the SharePoint list, or by editing the app if they have maker access. So if this restriction is about guiding people to the right choice, the in-app check is exactly right. But if it’s about data integrity or genuine security, treat the app as the UX layer only, and back it up server-side:

  • A Power Automate flow on item creation that rejects or flags an unauthorised value.
  • Tighter list permissions, so the people who shouldn’t set the value can’t reach the data behind it.

The in-app check is the polish. It shouldn’t be the lock.

Summary

With this setup, you now have:

  • A dropdown that hides restricted options from users who shouldn’t pick them
  • A Next-button fallback for when the option needs to stay visible but gated
  • A permission source you can keep outside the app so access changes don’t need a republish
  • A clear understanding of where the client-side line is — and why real enforcement belongs server-side

Restrict what people see to keep the app clean, validate what they do to keep it honest — and enforce what actually matters at the source.