Add the SharePoint App Permissions list as a data source. Create scrLoading, scrHome and scrAccessDenied. Set App.StartScreen to:

scrLoading

Keep scrLoading free of business data. Show a short “Checking access” message and a non-sensitive brand mark.

This formula normalises the current user’s sign-in identity, retrieves their active permission record and routes unknown or inactive users to a denied screen.

Set(
    varCurrentUPN,
    Lower(User().Email)
);

Set(
    varPermission,
    LookUp(
        'App Permissions',
        UserUPN = varCurrentUPN &&
        Active = true
    )
);

Set(
    varIsAuthorised,
    !IsBlank(varPermission) &&
    varPermission.Role.Value <> "Inactive"
);

If(
    varIsAuthorised,
    Navigate(scrHome, ScreenTransition.None),
    Navigate(scrAccessDenied, ScreenTransition.None)
)

User().Email returns the current user’s UPN, which can differ from their SMTP email address. Populate UserUPN with the identity Power Apps actually returns. Test guest and changed-name accounts explicitly.

Set each navigation item or action button’s Visible property. Super Users inherit all capabilities; other roles need the relevant flag.

varIsAuthorised &&
(
    varPermission.Role.Value = "Super User" ||
    varPermission.CanCreate
)

varIsAuthorised &&
(
    varPermission.Role.Value = "Super User" ||
    varPermission.CanEdit
)

varIsAuthorised &&
varPermission.Role.Value = "Super User"

If(
    varPermission.Role.Value = "Viewer" ||
    !varPermission.CanEdit,
    FormMode.View,
    FormMode.Edit
)

Use DisplayMode.Disabled instead of hiding an action when people need to understand that the capability exists but is unavailable. Add accessible labels that explain the state.

A hidden menu item is not enough. A saved link, deep link or formula can still attempt navigation. Add a guard to the OnVisible property of each restricted screen.

If(
    !varIsAuthorised ||
    !(
        varPermission.Role.Value = "Super User" ||
        varPermission.CanEdit
    ),
    Navigate(
        scrAccessDenied,
        ScreenTransition.None
    )
)

Permission changes are cached in varPermission for the current session. Add a “Refresh access” action for support use, or require the user to reopen the app after an access change.

Refresh('App Permissions');

Set(
    varPermission,
    LookUp(
        'App Permissions',
        UserUPN = varCurrentUPN &&
        Active = true
    )
);

Set(
    varIsAuthorised,
    !IsBlank(varPermission) &&
    varPermission.Role.Value <> "Inactive"
);

If(
    !varIsAuthorised,
    Navigate(scrAccessDenied, ScreenTransition.None),
    Notify(
        "Your app access has been refreshed.",
        NotificationType.Success
    )
)

For an urgent leaver or compromised account, remove access at the SharePoint and identity layers as well. An app refresh button is not an emergency revocation control.

Use separate test accounts for each role. Do not rely only on temporarily changing your own row because cached sessions and elevated maker access can conceal defects.