Implementing Role-Based Security in Power Apps with SharePoint

The building blocks

• A SharePoint list AppRoles mapping user emails to roles.
• A collection loaded once at app start with the current user's roles.
• Boolean helper variables (varIsAdmin, varIsManager, varIsReader) exposed everywhere.
• Visible / DisplayMode properties driven by those variables.

1. Design the SharePoint list

• Title (used as the user's email)
• Role (Choice: Admin, Manager, Reader)
• Active (Yes/No, defaults to Yes)

Restrict list permissions: only administrators can edit. All app users need Read permission so the app can query it.

2. Load roles at App.OnStart

Set(varUserEmail, User().Email);
ClearCollect(
  colUserRoles,
  Filter(AppRoles, Title = varUserEmail && Active = true)
);
Set(varIsAdmin, CountRows(Filter(colUserRoles, Role.Value = "Admin")) > 0);
Set(varIsManager, CountRows(Filter(colUserRoles, Role.Value = "Manager")) > 0);
Set(varIsReader, CountRows(colUserRoles) > 0);

3. Apply roles to controls

// Admin-only button
Visible = varIsAdmin

// Read-only form for non-managers
DisplayMode = If(varIsManager, DisplayMode.Edit, DisplayMode.View)

4. Screen-level guard

On the OnVisible of restricted screens, redirect unauthorized users to a friendly Forbidden screen instead of hiding controls piecemeal.

5. Never trust the client alone

Client-side role checks make the UI friendlier - they do not secure the data. Combine them with SharePoint item-level permissions or Power Automate flows that enforce authorization server-side before any write.

Pitfalls

• Do not store roles on the same list as your business data - separation matters for audit and RLS.
• Refresh colUserRoles whenever an admin adds/removes a role, or ask users to reopen the app.
• Handle the case where the user has no role: show a Forbidden screen, do not leak the app.

Wrap up

A simple list, a few variables and disciplined use of DisplayMode/Visible cover 90% of the role-based security needs of internal apps - without a Dataverse licence.