When you are deciding if you want to approve an action, you probably want more information then a description. Luckily we can add a link to our Approval request! This is a follow up on my previous post where I showed how to trigger an Approval inside a Business Process Flow. In this blogpost I will show you how to generate a link to the record we are working on.
This blog is part of a series about guiding users and teams through their work. This post is about Approval Flows inside Business Process Flows. Click here for an overview of all related post regarding Approvals inside your Business Process Flow. I also added a sample solution you can import in your own development environment so you can see the entire concept in action!
Keeping people in their flow of work by utilizing Asynchronous work or asynchronous processes is one of the key benefits for Business Process Flows. I have written down my thoughts on this subject here. Find out what asynchronous work is, how Business Process Flow can help and more advanced scenario’s.
The Item link property
As mentioned in the introduction, it is very convenient to be able to navigate to a record when you want to give approval. As a manager you can view all related information and see if everything is in place.
To do so we can fill in the Item link and item link description of the Approval action “Start and wait for an approval”. The Item link property is for the URL and the description is the text that will be shown for the hyperlink.
However we do not know the record link inside the Approval flow. We will need a few tricks to generate the link to the Model-driven App record. It is also important to keep in mind that this Flow needs to work across multiple environments as we are currently working in a development environment. When I transfer our solution to the test or production environment I do not want to manually change the URL
Examine the Record Url
Let us first take a look at the URL of a model-driven app record as we want to replicate this in our Item Link.
There are a couple of properties which are dynamic and which we need to change:
- “orgff248fa5”. The environment name of your Power Platform. If you are not working on a developer environment you probably have set this to a more readable name 😅
- “appid”. The Model-drive application Id which we want to open. If there is only 1 application in the environment you could skip this. However I recommend to set this as well, it’s only 1 extra step in your flow.
- “id”. The Id of the record.
Grab the current URL from a Dataverse action
To get the environment name we are working in, we can use a little trick. This trick will also give us the base part of the link to the model-driven app we eventually need. In the outputs of the update action we get a few URLs we can use. For example the OData ID we see below. This is actually the direct API link to the record we just updated.
To use this URL in the Link we build op later we have to put it in the Compose action. This will change it from an object to a string.
When we build up the Link we will use the function function “uriHost”. This function will give us the base part of the URL. In our example this will give us: “orgff248fa5.crm4.dynamics.com” and thus gives us the Environment name too!
Retrieve the App Id stored in Dataverse
Nowadays we build multiple Apps on the same environment. Apps specific for a certain use case or role. This however makes it required to add the AppId in the Link we want to build up. Luckily all the Model-driven Apps are stored in Dataverse in the table Model-driven Apps. So we can retrieve them using a List Item action:
We only need the appmoduleid as this contains the Id we need. So we only select that column. I actually found out about this table by a blogpost from Sara Lagerquist. It contains the following quote:
“The List Record action is not a buffet, it’s an a la carte menu. You do not order the whole menu of food and then pick an choose what to eat. That would be too expensive. You decide before hand what to order and make sure you consume it all.”Sara Lagerquist
Which of course is good practice for performance of your flow. The filter uses the “Name” and not the “Display Name” of the app:
uniquename eq 'bdenb_CaseManagement'
Building the Url for the Item Link
Now that we have all the necessary properties we can build up the Url for the Item Link. For readability I like to use a specific Compose action for the URL. We start of the url with “Https://”
After which we use the function uriHost with the parameter the OData Id we put in a compose. This will give us the base part of the url. We follow up with the string “/main.aspx?appid=”. Main.aspx is the default page the Model-driven apps live in. After the question mark of the Url we can build up the parameters. This first one is the AppId.
We add the AppId dynamically from the List Items action. This will of course return only 1 record. Thus we can safely use the First function.
Now we add “&pagetype=entityrecord&etn=bdenb_case&id=”. This will tell the App that we want to navigate to a specific record of the table “bdenb_case”, which is my own case table. After the id we will use the record id from the “Update record” action.
This will now give us the following code in the component action:
Now for the final result
We are now nearly done! Add the output of the compose action to the “Item link” property of the Approval action. And we add a “Item link description” for the text of the Url. I added the “Name” of the record of the approval for clarification.
Now that we are done let me show you the result in the Microsoft Teams Approval center:
Adding the Item link puts the finishing touch on our Approval request. This ensures easy access of the information required by the Approver. With the technique I described in this post we can ensure this works in ALM scenario’s as well.