Role-Based Access Control in Canvas Apps: A Step-by-Step Guide

When building a Power Apps canvas app for a team, you quickly run into a common challenge: not everyone should see or do the same things. A team member might need to view and update only their own tasks, a project lead should oversee all tasks within a project, and an administrator must be able to delete or reconfigure records. Instead of building separate apps for each persona, you can create a single adaptive interface that changes based on the logged-in user's role.

In this guide, we'll walk through a "Project Task Tracker" app that uses a SharePoint list to store user roles and applies conditional logic in Power Apps to control visibility and data access. You'll learn how to filter a gallery, show or hide controls, and handle role assignment gracefully.

Scenario: Project Task Tracker

Imagine your team manages a portfolio of projects. Each project has tasks assigned to different people. You want:

• Team Member — can only see and edit their own tasks.
• Project Lead — can see all tasks across their assigned projects.
• Administrator — can see all tasks and has the ability to delete any record.

We'll use two SharePoint lists:

• UserRoles: contains the mapping between a person and their role.
• Tasks: contains the task details.

1. Prepare Your Data Sources

UserRoles List

Create a SharePoint list named UserRoles with these columns:

Populate it with your team:

Tasks List

Create a second list named Tasks with:

Add some sample data:

Now go to Power Apps and create a new canvas app from blank. Save it (e.g., "Project Task Tracker").

2. Determine the Logged‑In User's Role

When the app starts, we need to identify the user and look up their role from the UserRoles list. If no mapping exists, we assign a default role (e.g., Team Member) and optionally create a new record.

Navigate to the app's OnStart property and enter:

Set(
loggedInUser,
User()
);

With(
{
  roleRecord: LookUp(
    UserRoles,
    User.Email = loggedInUser.Email
  )
},
Set(currentUser, roleRecord.User);
Set(currentRole, roleRecord.Role.Value)
);

// If no record found, assign default role and optionally create entry
If(
IsBlank(currentRole),
With(
  {
    newRecord: Patch(
      UserRoles,
      Defaults(UserRoles),
      {
        User: {
          '@odata.type': "#Microsoft.Azure.Connectors.SharePoint.SPListExpandedUser",
          Claims: "i:0#.f|membership|" & loggedInUser.Email,
          Department: "",
          DisplayName: loggedInUser.FullName,
          Email: loggedInUser.Email,
          JobTitle: "",
          Picture: ""
        },
        Role: {Value: "Team Member"} // default
      }
    )
  },
  Set(currentUser, newRecord.User);
  Set(currentRole, newRecord.Role.Value)
)
);

Explanation:

• loggedInUser stores the current user's details from User().
• LookUp searches UserRoles for a record with a matching email.
• If found, we store the user and role in global variables currentUser and currentRole.
• If not found, Patch inserts a new record with the default role. This automatically adds the person to your security list.

3. Show the User's Name and Role in the App

Place an icon (e.g., Person) in the title bar and a label next to it. Set the label's Text property to:

currentUser.DisplayName

Add a lock icon and a second label for the role:

currentRole

Your app now shows who is logged in and what permissions they have.

4. Filter Tasks According to Role

Add a Vertical Gallery (or Modern Gallery) to the screen and connect it to the Tasks list. We want:

• Team Member → only tasks where AssignedTo.DisplayName equals the current user's name.
• Project Lead → all tasks (but in a real app, you might filter by project or team).
• Administrator → all tasks.

Set the gallery's Items property to:

Switch(
currentRole,
"Team Member",
Filter(Tasks, AssignedTo.DisplayName = currentUser.DisplayName),
"Project Lead",
Tasks, // or Filter(Tasks, ProjectLeadID = ...) for more granularity
"Administrator",
Tasks
)

You can also use an If statement, but Switch is cleaner when handling multiple options.

Delegation note: The Filter with AssignedTo.DisplayName will be evaluated client‑side if the SharePoint list has more than 500 items. If you anticipate a large dataset, consider storing the user's email as a text column instead of a person column to enable server‑side filtering. For this demo, it's fine.

5. Conditionally Display Controls (e.g., Delete Icon)

Only the Administrator should be able to delete records. Add a Trash icon inside the gallery and set its Visible property to:

currentRole = "Administrator"

When the user is not an admin, the icon disappears, preventing accidental clicks. You can apply the same pattern to any other control — edit buttons, admin panels, etc.

Performance and Security Considerations

• OnStart efficiency: The LookUp and Patch only run once at app start. Avoid expensive operations inside galleries or repeated loops.
• SharePoint list permissions: Power Apps controls visibility, but always secure the underlying data source using SharePoint permissions or row‑level security with Power Platform Data Policies. This prevents a determined user from bypassing the app and accessing the list directly.
• Delegation: As mentioned, Filter on a Person column's display name does not delegate to SharePoint. For large lists, either use a single‑line text column for the user's email or switch to a delegable query like Filter(Tasks, AssignedTo.Email = currentUser.Email). However, email matching may still have delegation limits. An alternative is to filter by a choice column or numeric ID.

Common Mistakes and Troubleshooting

1. User not found in the list If the LookUp returns nothing and you haven't added a default fallback, currentRole will be blank, causing all conditional checks to fail. Always include the If(IsBlank(...)) block.

2. Hard‑coded testing email left in production During development, you might temporarily override loggedInUser with a specific email. Make sure to remove that test line before publishing.

3. SharePoint choice column vs. text column When using a Choice column, the value inside Power Apps is an object with a .Value property (e.g., currentRole becomes "Team Member"). If you create a text column instead, you can compare directly. Choose one approach and stay consistent.

4. Delegation warnings ignored If you filter on a non‑delegable function (e.g., StartsWith, In, or Left on a person column), you'll only get back the first 500 records. Use delegable comparisons when possible.

Tip: Testing as Another User

To quickly test how the app behaves for different roles, you can temporarily hard‑code the lookup email:

Set(loggedInUser, User()); // Keep as is

// For testing, uncomment the next line and replace the email
// Set(loggedInUser, {Email: "carol.diaz@company.com"});

Then replay the app's OnStart (File → App settings → OnStart → Run). This simulates that user and their role. Don't forget to revert before publishing.

Final Recommendation

Role‑based interfaces in Power Apps don't require complex custom connectors. With a simple SharePoint list to track roles, a few global variables, and conditional formulas, you can build an adaptive UI that feels tailored to each user. Start small — define your roles, test with real people, and expand the logic as your app grows.

For production apps, always layer your security: control visibility in the UI, enforce permissions at the data source, and regularly audit who has access to your lists.

References

This guide builds on ideas originally discussed in Matthew Devaney's article Designing A Role-Based User Interface In Power Apps. You can find the original at https://www.matthewdevaney.com/designing-a-role-based-user-interface-in-power-apps/.

For official documentation:

• Power Apps – Filter function (Microsoft Learn)
• Power Apps – User function (Microsoft Learn)
• Understanding delegation in Power Apps (Microsoft Learn)