PowerApps Security Trimming Options
A common requirement when building out forms/applications in PowerApps is to apply security trimming to elements in your app. Take this scenario for example: You have a form which requires an approval. You only want certain users to be able to click the button to mark the form as approved. As with anything in PowerApps, there are multiple ways that you can accomplish this.
Approach 1 – Custom Connector w/ Azure AD
One way is to use a custom connector and Azure AD to handle it which this blog post from Microsoft outlines. This approach is probably the most costly from both a time and a licensing perspective. Since it utilizes a custom connector and Azure AD, you need both access to Azure AD and premium licensing to implement the custom connector. However, it is a robust and scalable way to handle permissions which enables you to utilize existing Azure AD groups.
Approach 2 – SharePoint Group w/ Flow
Another approach is to use SharePoint Groups and our friend Flow to search through a SharePoint Group and see if the current logged in user belongs to that group. Geetha Sivasailam has a great blog post on how to implement role based security with the SharePoint Group/Flow approach that you can read here.
This approach will work within your standard O365 PowerApps and Flow licensing. The only real downsides to this approach is it is dependent on SharePoint Groups therefore, you will need Full Control permissions to configure the group. Additionally, it’s dependent on Flow so it will count against your Flow run quotas. If you need this security trimming in multiple apps or sections of apps and your apps are utilized heavily then this approach could really eat into your allotted Flow runs.
Approach 3 – SharePoint List
I’ll offer a third approach for handling security trimming which utilizes a SharePoint list. You can create an “Approvers” list in SharePoint, add the users which should have permissions to access the button in your PowerApp to the list and then query that list in PowerApps to see if the current logged in user is in that list. Here are the steps involved :
- Create an Approvers list in SharePoint. You can keep it simple and utilize the Title field to hold the Name or Email address of the users which should have the necessary Approval permissions. For this example, I’ll put the user’s name in the Title field and match on that. It’s probably a better idea to match on Email because that is ensured to be unique
- Add the Approvers list as a data source in your PowerApp
- Select the “App” tab and go to the “OnStart” Property. You need to check and see if the current logged in user exists in the Approvers list. You can do that by creating a collection which filters the Approvers list like so:
ClearCollect(acceptedApprovers, Filter(Approvers, Title = User().FullName))
- Now you need to go to the button (or whatever control you are wanting to restrict). Depending on your use case you may want to completely hide the control if the user doesn’t have access or maybe you just want to disable the control.
Hiding the Control
Go to the “Visible” property of your control and paste in the following:
Locking Down the Control (still visible but not editable)
If you want to make a control visible but not clickable or editable you can go to the “DisplayMode” property of your control and paste in the following:
Additionally, if you have a button you might want to change the fill color to a gray color if it is disabled so that the user has a visual cue that the control is not clickable.
To do this, go to the “Fill” property of the control and paste in the following (gray = whatever color you want to show if disabled, green = whatever color you want to show if enabled):
Benefits and Addressing Security Concerns
The main benefits of this approach are simplicity and cost. You can accomplish security trimming with no additional licensing costs or Flow run hits.
You might wonder if this approach is really secure because you have to grant your users access to that SharePoint list so what would be prohibiting them from going to the list and changing permissions? Well, in this case, we are only using that Approvers list to read data, not write. So from the SharePoint side, you only have to grant your app users View Only permissions to the underlying list. As long as you have your SharePoint permissions set to View only, you don’t have to worry about your users going in and messing with the permissions.
I’m only highlighting ways to security trim WITHIN THE POWERAPPP ITSELF. This post is not meant to address how you could apply security trimming to your underlying SharePoint data source. If you want some ideas on how you can manage the security of your underlying SharePoint datasource, check out Laura Rogers blog here which runs through several options for “locking down” your SharePoint list data sources so that users aren’t going to the list directly to edit data.
For the visual learners here’s a video that walks through the steps to implement: