Canvas App on LinkeD365 Blog

Approvals - Showing History in SharePoint

Sun, 07 Jun 2020 00:00:00 +0000

Last week, I took part in the Microsoft 365 Virtual Marathon. This was a branch out for me, as it wasn’t specifically Dynamics 365 or Power Platform related, though everything is one now right?

My talk was around Approvals, displaying 3 types of approvals, from a Send with Options to Adaptive cards, topics I have covered in my blog before.

During the sessions, one of the questions was around tracking approvals. Even in the Approvals app, it is very difficult to track who has approved and when including the comments. If you want to see this in combination to the thing you were approving, it means swapping between apps and ensuring you know what record you are looking at.

I took this as a challenge, and decided to use the Power Apps in SharePoint form to display Approvals.

TL;DR

Display of Approvals in SharePoint or and Power Platform application is not intuitive. I use a Power App to display approvals against items on a SharePoint document library.

Form in Action

Before I run through the detail, check out the form in action below. As you show more details and display the associated Power Apps form, a list of the approvals is shown. If you drill into the approvals, more details about who it was sent to and how they responded are available.

Simple Approval

To get some approvals, I created a flow which is triggered when a file is added to the SharePoint folder. Obviously, this could be a lot more complex than this, but this simple one is to get some data in my approvals to show in SharePoint.

The critical part of this is the item link. You need a method of linking your approvals with the item it corresponds to, and MS does not provide you with a key field. You could create an approval, update a bespoke field on the document meta with the approval id, but I did not want to create unnecessary fields. I ensure that the item link will take me to the document in SharePoint.

SharePoint form

First of all, using Power Apps in SharePoint is not the same as a standard Power App. It frightened me when you start the Power App that it dumps you into the Default Instance. Also, these applications are not solution aware. I don’t think you can share the forms either. It is certainly not what I am used to. Not sure why this is the case. Let me know if you know any different.

In the document library, select Power Apps, customise forms.

The form I created has a SharePointIntegration property in it, which is the context that is passed in. The form is linked to that record, in my case a document.

There are a couple of triggers on the integration which are used to force the display of the first screen when this is triggered. If you don’t apply this logic, the screen that was displayed last will return to the user, meaning the user tends to be left in the second, approval details screen.

I have added a couple of fields to the top half of the form, which represents some of the core fields you need. Below that, I have added a gallery.

Also, to use later, onvisible takes the document that is passed in or the first in the list and sticks it in a local variable

The Gallery Items is a filtered list of the Approvals entity within your CDS environment.

Here, you can see that I am filtering the Approvals entity by the item link, using the base SharePoint URL and the full path to the file. This isn’t the full path, just the bit after your site collection.

In the gallery Item are 3 fields. The first field is a visual indicator of the current status of approval. It is a combination of the Status reason as well as the result.

This label is also coloured to show Approved as green, Pending as black & Rejected as Red.

The next fields is just a display of who created the approval and when.

I added a second screen to my app, so you can see the detail of the approval, navigated to by selection of the approval.

Approval Detail

This form is pretty simple looking, with just a gallery. On visible of the form, two collections are populated, which are filtered lists of Approval Requests and Approval Responses. Working with local collections is a lot easier, particularly if you need to reference them multiple times.

The gallery is connected to the requestList, filtered by the previous step.

The name of the approver is taken from the owner of the request. I added a timestamp as well.

The third field combines several, depending on whether there are any responses to the particular request by the user. Also, the status, even for those that have been classified as rejected, is Active. There does not seem to be any direct link between the request and its response. I am assuming that each request can only have 1 response by 1 person, so filter the already filtered responses by the user who is the approver. Colour coding on the value again gives a more visual representation.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


If(
 IsEmpty(
 Filter(
 responsesList,
 'Owning User'.'Full Name' = ThisItem.'Owning User'.'Full Name'
 )
 ),
 If(
 Text('Status Reason') = "Active",
 "Pending",
 Text('Status Reason')
 ),
 Text(
 First(
 Filter(
 responsesList,
 'Owning User'.'Full Name' = ThisItem.'Owning User'.'Full Name'
 )
 ).Response
 )
)

There are a couple of other fields on the grid, firstly the Comments entered if there are any. This comes from the response. I trigger the visibility of this field depending on whether it has a value.

Finally, who re-assigned the request. Here I use a lookup, which allows a traversal to the the users name.

Launch (Self) - Check App permissions in Power Apps

Fri, 22 May 2020 00:00:00 +0000

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.

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.