In this article I will explain how to create deep hyperlinks to your PowerApp and walk through a simple example to apply this technique.
Deep linking consists of creating an hyperlink which not only will take the person using the link to your app, but for instance to a specific screen, or even to a specific view of a specific screen. In this example, we will show how to craft a URL which will take a user past the initial screen, into a further screen in the app and show the user a filtered list based on the value provided in the URL.
To understand deep linking, we must first understand how PowerApps URLs are structured. You can access your app’s URL from the portal, going into the “details” section as shown below :
Powerapps base URLs are made of 3 sections : the generic prefix “https://apps.powerapps.com/play/” followed by the app ID, followed by the tenant ID.
Deep linking consists of appending additonal bits to the base URL to access specific screen in the app instead of just landing on the front page.
Creating a parametrized URL
In our example, we are going to create an URL that bypasses the first screen of our app, navigates to the second screen and displays a gallery filtered on a specific item. For this we are going to use a parameter named FilterOnItemId which the app will consume to serve the requested screen and view to the user clicking on the link.
Our parametrized URL will look like this : https://apps.powerapps.com/play/my_app_id?tenantId=my_tenant_id?FilterOnItemId=2
Consuming the parameter in the app
In the app, we now need to add code to consume the parameter and serve the requested view which consists of perfoming 2 actions :
- Navigate to screen 2
- Filter gallery on the item specified in the URL
The OnStart property of the app is a good place to add parameter consumption steps as these steps will be executed first when the app fires which gives us the opportunity to drive different behaviour based on whether a parameter has been provided or not.
Param function allows to access the value of parameters passed via the URL – so in our case,
Param(FilterOnItemId) would evaluate to 2 within the app session generated by the URL we have created earlier. It would however evaluate to Blank() is a session generated by the App base URL.
We can therefore drive our desired behaviour by specifying the following code in the OnStart property :
If the app is started from the base URL, initialisation will elapse and users will be taken to the landing page – of however it is started from the parametrized URL, the app will pick up the parameter and navigate to screen 2 directly.
In order to achieve the second action, which is to filter the gallery on the item specified in the URL, the same sort of condition can be used in the Items property of the gallery to sort in Screen 2 :
If( !IsBlank(Param(FilterOnItemId)), Filter(Screen2GalleryItems,ItemID = Param(FilterOnItemId)), Screen2GalleryItems )
You will have noticed that the app consumes the parameter provided in the URL as a variable, therefore, two users given two parametrised URLs with different parameter values will experience 2 different views. This can be used for example in an app where a set of users create items and another set approve or reject these items. When rejecting an item, an email containing a paramerised URL using the rejected item’s ID can be sent to the relevant person for that person to click and be taken straight to the rejected item in order for example to make corrections and resubmit, which makes for a better user experience that having to manually look for the item to edit it.