Featured image of post Launch (Self) - Check App permissions in Power Apps

Launch (Self) - Check App permissions in Power Apps

On the Twitterverse yesterday, it was announced that you now have the ability to Launch an application to replace itself.

https://powerapps.microsoft.com/en-us/blog/formulas-launch-to-self-and-self-operator/

@Sancho Harker, @EY Kalman, @Clarissa Gillingham and I had a discussion about the uses of this new feature, and the thing I mentioned was that you should be able to do an app which is a central repository, an app selector. The problem I saw was that you needed to know if a user had access to an app. If they have access, show the app button, if not, don’t display it.

As a user, having a button that gives an error is infuriating.

I knew there were admin connectors for Power Apps in Power Automate, and you could use the action Get App Role Assignments as Admin from the Power Apps for Admin connector to get a list of people who had access to an app, but would this work? Surely you needed administrative access to use this connector? So, I had to do a proof of concept to make it work.

The Flow

Firstly, this is an HTTP Request. The reason being the connectors needed are Admin only, Environment Maker is needed to use the administrator connectors, so this Flow needs to run as an admin user.

This whole piece could be simpler if I could call this from a Power App directly, but this restriction means we need a two-hop method, two flow runs, though the first step should be covered by the Canvas app licence and the second, this flow, needs to be an administrator with a Per user Plan.

The JSON body is simple, just an AppName and Email of the user, both strings.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
{
    "type": "object",
    "properties": {
        "AppName": {
            "type": "string"
        },
        "Email": {
            "type": "string"
        }
    }
}

Next, get your app permissions. This is in a couple of steps, so this Flow can move between environments. First, get a reference to the current environment. Next, get all the Apps in that environment. Finally, filter this list to only the one sent in in the HTTP parameters.

There is a property of the returned app which is the Display Name. This is what is used to filter and match on, comping from the HTTP request.

Now we can use the Get App Role Assignments as Admin connector to retrieve a list of users who have been given permission to our application.

The PowerApp Name I am interested in is for the first one returned, so use an expression like above to prevent a Apply to Each loop.

As this action could fail, it is the first time a connector is asking for something, configure a run after. Positive is for carrying on, failure we respond to http request.

On the success side, filter the list of role assignments, checking for a Tenant type. This looks for a situation where you have shared the application with “Everyone”.

Check to see if the returned array has any items in it.

If there is, respond positively.

If no tenant access, check for specific user access by first filtering to only all the user principal types.

Then check for the users email that was passed in.

Finally, check that this array has values in it and respond accordingly.

That is all for the main flow. Now to call this from PowerApps.

Calling Main Flow

To call the flow, you have to get Power Apps to call a http request, not directly possible, but if you put a wrapper around your flow like below, it can be done.

Firstly, the trigger is PowerApps. Next call the primary flow above. The body sent contains 2 fields you ask for from the Power App. Unfortunately, you can not, yet, rename these variables.

Parse the response from this so it makes it easier to return the response and respond to Power Apps.

App Launcher

The App Launcher solution looks like this now.

The App Launcher is configured with 3 buttons.

Each button is configured to launch one of the other apps. This is the App Id. The default is to launch self, so no need for another parameter. This is all documented well in the Microsoft Launch documentation.

The visibility of each button is controlled by variables, here for our secret app button.

On launch of the application, use the Flow above to populate the visibility variables for each button.

Sharing the Apps

Now it is all up and running, lets just check the access. For App Launcher, App 1 and App 2 I have shared with the whole tenant, as shown here.

The secret app is not shared with everyone though.

Launching the App Launcher as my admin role, you can see the buttons become visible as the code is run.

For Veronica, who doesn’t have access to the secret app, her experience is the same, but she never sees the third button.

This solution is not perfect, it is missing any groups you are a member of, which is a big part of sharing apps, but just lets you know it is possible.

comments powered by Disqus
My views, nothing to do with anyone else
Built with Hugo
Theme Stack designed by Jimmy