When configuring canvas apps, all controls you put into your canvas are always visible to all users by default. But some controls should not be available for some users (e.g. Delete of Edit buttons). In this blogpost, I will explain how to configure this kind of control-based security.

Introduction

In this blogpost, I will use a simple configuration using both SharePoint. and Power Apps.

SharePoint is being used to control the security in your canvas app. The Power App uses a simple canvas with a Gallery, Form and a few buttons in which the buttons are using contol-based security.

SharePoint

A minimum of 2 lists is required for this to work:

1. A list to store your process information
2. A list to handle the control-based security

The Process information list is pretty straight forward. The configuration depends on your process and can contain anything you want. In my case, I only have the Title column for demo purposes.

The Security list is a simple list with only a Title column. It contains all roles that you want to have available in your Power App; the Title column describes this role. In my example, I’ve configured 3 roles:

• Admin
• Editor
• Reader

The idea is that you have a role with full permissions (Admin), edit (no remove) permissions (Editor) and read permissions (Reader).

In order to have your Power App know which role belongs to which users, you need to configure custom permissions on this list and its items. For this, I just use the default SharePoint security groups: Site Owners, Site Members and Site Visitors. Each group contains the people who should have the corresponding role in the Power App. You can configure other groups if you want, but make sure to always have a separate group for each role that you need in your Power App.

List permissions

By default, the Members group has edit permissions on everything within your SharePoint site. You don’t want your Members to change anything within the Security list, so make sure you provide them only with Read permissions on this list. You can do this by selecting Stop inheriting permissions and changing the Edit permission for the Members to Read. Make sure your Visitors group also has Read permissions (this is by default, but you might have changed that before). The default Owners group contains the site owners, so they can keep their Full control permission. If you use a different group that should only have Admin rights on the Power App controls, you might want to change its list permission to Read as well.

For the Process information list, I also changed the list permissions a bit, since Members should not be able to Delete items. I created a custom permission level that allows editing, but not deleting. I will not go into detail on how to configure this, but you can always leave a comment if you need to know more about this.

Item permissions

Each item in the list should be ‘assigned’ to its corresponding SharePoint group. This can be done by assigning unique permissions for each item by selecting Manage access from the context menu, followed by Advanced settings:

In the Permissions screen, you need to choose Stop inheriting permissions and assign the following permissions to each item:

• Admin: Owners (Full control)
• Editor: Owners (Full control), Members (Read)
• Reader: Owners (Full control), Members (Read), Visitors (Read)

Again, if you’re using a separate group for the Admin role, you might want to change the item permissions to Read as well.

Power Apps

The Power App in this example is just a simple (totally not visibly appealing) representation of how to set this up. It uses a Gallery to show all existing items within the Process information list, a few buttons (New, Save, Edit, Delete and Cancel) and a form to show the selected item from the Gallery. I will not go into detail in how to configure the Gallery, Form and default button behavior. If you have any questions about that, please leave a comment.

This is the default Power App configuration, so every button is visible for each role. But not each role has the functionality for that button (e.g. Visitors should only be able to view items and Members should not be able to delete items). This is where the configuration we just made in SharePoint comes in.

Check role

To check the role of the logged in user, we simply need to pull the contents of the Security list into our Power App and check which items the user has permission for. First, I will store the contents of the entire Security list into the colSecurity collection in the OnStart of my Power App:

ClearCollect(
    colSecurity,
    'Control based security demo - Security list'
);

After that, I will check the role of the user by checking each item one by one (by using a Lookup on the item IDs) to make and store the corresponding role into the varRole variable:

Set(
    varRole,
    If(
        Not(
            IsBlank(
                LookUp(
                    colSecurity,
                    ID = 1,
                    Title
                )
            )
        ),
        "Admin",
        Not(
            IsBlank(
                LookUp(
                    colSecurity,
                    ID = 2,
                    Title
                )
            )
        ),
        "Editor",
        Not(
            IsBlank(
                LookUp(
                    colSecurity,
                    ID = 3,
                    Title
                )
            )
        ),
        "Reader"
    )
)

If a user doesn’t have permissions on the Admin item, the Lookup function will give a blank value resulting it to go to the Editor check and so on. If a match on the item is found, the corresponding role will be stored in the varRole variable.

Button visibility based on role

The varRole variable is what triggers the visibility of the buttons in the Power App. Since each role is now defined in the varRole variable, we can use conditional visibility on our buttons by configuring the Visibility attribute of the buttons with the following FX Formulas:

New / Save / Edit / Cancel

Creating new items and editing existing items should only be allowed for Admins and Editors. Therefor, these buttons should only be visible for these roles. Since the Save and Cancel buttons are related to the New and Save buttons, these should also be hidden for Visitors:

If(
    Or(
        varRole = "Admin",
        varRole = "Editor"
    ),
    true,
    false
)

Delete

Deleting items should only be allowed for Admins. Therefor, this button should only be visible for this role:

If(
    varRole = "Admin",
    true,
    false
)

Result

For demo purposes, I’ve added a label that displays the role of the user.
If everything is configured properly, Admins should show the Admin role and see all buttons:

Members should show the Member role and see every button, except for the Delete button:

Visitors should show the Visitor role and don’t see any button: