Simplified Access Management

The PowerApps platform as a whole does a reasonable job w/ sharing of applications and restricts things down to a degree that I'm mostly happy about.  However, there are exceptions to this rule and sometimes it is easier to share applications with the entire organization and then trim down from there.  

Sometimes it is also helpful to make the approval process a little more "business friendly" for allowing people to have access to the application vs. training them on anything relating to the Power Platform as a whole. 

This walks through an example of how to set up an app where you can share it with your entire organization and then trim down from there.  The entire thing is managed from several SharePoint lists or honestly, whatever you decide to do within your Power Automate script to assess if someone's allowed to use the app or not.

TLDR

This consists of:

• Splash Screen that calls Power Automate
• Hidden popup that appears if the user is not allowed to access the app
• Power Automate script that is called to see if the user is allowed to access the app
• (Optional) SharePoint list(s) that include business-managed entries for users

 

Counts rows returned from either department or users list

The logic can be anything, but if you set up your Power Automate script to run as a service user, then the end-user will not receive a warning about accessing SharePoint or the User Profile connector.  If a user is not allowed to access the app then they will receive a popup message and block progression.

Managing Access

In my example, I am checking to see if the person is in any of the departments that are allowed to use the app, or if they are in an "exemption" list that allows people access on a user-by-user basis.  This allows departments to self-manage access only by editing these lists.

The plus side of this is of course that you don't have to know anything about Power Apps to do anything here.  But you do have smack people when they make typos.  YMMV.

The first list I used here is a departments list:

The business is allowed to add/edit any of these and anyone who logs into the app who is a member of these departments (as matched in the Get User Profile V2 lookup) is allowed.

If someone's account in Entra/AD has a department value that matches these, then they can access the app.

The second list I use is to allow one-off user's to be granted access.  

This allows any single user to be added to the list for solo exemptions.

NOTE: I didn't have this in my example, but you definitely could include a Block List as well that would then remove someone who does match on department.

Power Automate Script

In my example script, I'm sending in the end-user's email at the start:

This allows you to also pass in test data vs. doing a lookup on the user who called the flow.

I am using the Get User Profile (V2) step to then pull up the specific end-user's department field:

Note: You of course can use any field that the User Profile will display.

I am then querying the SharePoint list to see if the department assigned to the end-user is in our list in SharePoint.  

Then I am querying a different SharePoint list to see if the end-user's email exists in our one-off list to allow individuals access:

Finally, I am checking to see if there are any items returned from either query:

The detail on this is the following code:

greaterOrEquals(add(length(outputs('Get_items_that_match_Department')?['body/value']),length(outputs('Get_items_that_match_Email')?['body/value'])),1)

What this gobbledygook means is, if we have 1 or more items in either list, then they are "approved" for access to the app.  I am using the length, add, and greaterOrEquals functions within Power Automate to do this calculations.  Length counts the # of items in the list.  Add combines those results.  Then greaterOrEquals gives us a Boolean result (0 results = false, 1 or more = true).

NOTE:  Again, if you also wanted to include a blocklist then you'd expand your logic here to query that and force the result to false

The final steps for your Power Automate is to probably set this up to have a Run Only users run as a non-end-user credentials so it can connect to your lists or logic that the end-user won't have the rights to connect to.  See my detailed notes here.

Then to associate your flow w/ your PowerApp:

The PowerApp

Add your Power Automate script now to your Power App.  

Your first screen now should be a splash screen that verifies if the person is allowed to access the app (and any other startup logic you want to run).  For that screen, add in a pair of controls that will display only if the user is now allowed to use the app:

These will have their Visible property set to the inverse of the boolean that returns from our Power Automate script.  So if they are NOT allowed, then the popup will become visible.  See my notes on Popups here.

Now, in your OnVisible code for your splash screen you'll close it out w/ the following logic:

UpdateContext({allowAccess: yourAutomateName.Run(currentUserEmail).allowaccess});

UpdateContext({showUserWarning: !allowAccess});

If(

    (!pauseAutomation) And allowAccess And (!showVersionPopup),

    Select(startingLogic)

);

The blue items should be updated to reflect your own process/variables.  I'm using my startup screen automation here that you might not use and I'm also using my version checking logic that again is optional here.

End-User Experience

For the end-users, you can now share this app with your entire organization.  However, if they are not in one of the departments in your list or are not in your one-off list, then they will get the popup and will not be allowed to use the app.

As well, the end-user will receive no warnings about access to allow the app using certain tools because all of these are through Power Automate and through a service account. 

Keep in mind that this probably isn't something you would do if you are using premium connectors and have a limited audience assigned to them.

You can optionally add in a workflow of approvals for access into your app directly or through emails to the process owner, etc.  This makes it completely flexible for access without needing to train anyone on anything more than managing a couple of lists in SharePoint.

You also might consider what a management interface might look like which you could make generic to copy/paste for each team that gets a new app.  For example. A people picker that allows you not only to do the exceptions but also the departments.  Doing a "sample user" and pulling the department from their Entrance/AD profile solves the typo problem nicely.

Final Thoughts

I have done an array of methods to allow access for applications around our organization.  Historically I just used the default tools, then some m365 Groups, then some Team memberships, then I did this.  I think managing through Teams membership isn't a bad move and you can do it similarly to how this is done, just ignore the lists and instead see if a person is a member of a particular Team.  However, that also kind of assumes that people who are part of this Team are the ones you want seeing this app.  Sometimes, that isn't the case.

Regardless of how you actually determine if someone is allowed to access the app, the design is the same except the steps within your Power Automate flow.  Everything else is identical:

1. build in custom Power Automate method to determine who can use the app
2. link app to Power Automate
3. block app from continuing if person isn't allowed to use it
4. share app w/ whole organization

It means you've got a pattern for widespread usage within your organization without a need to change depending on how a particular department wants to control who can/can't use an app.

This is similar to my Version Control approach in that you can simply copy/paste this into all your apps as you go forward without needing a complex centralized system unless you want one.  But the overall actions are the same.  It lets you take control over who can access you app in a very custom way but it also makes it very repeatable with minimal action on your part so the business can manage their own access requests.

As an alternate approach, you can also start workflows to automate access requests using the standard sharing methods if you have a way to catch those emails to request access.  See my walkthrough here.