In 2020 I published a WTF episode that shared how to create a dynamic record URL for a model-driven app. This was to replicate the built-in functionality of classic workflows of creating a Record URL. It's typically used in use cases where you require a user to click on a hyperlink to load a row or view in a model-driven app.

The flaw with the method I shared is that it's using the Dataverse List Rows action to retrieve the appid query parameter value from the table called "Model-driven apps." This meant that the action needed to be included in all cloud flows that required a dynamic record URL for Dataverse or Dynamics 365. Not ideal as each action consumes an API call. Check out Jerry Weinstock's blog post that briefly covers what counts as an API call. Otherwise refer to the Microsoft Learn documenation.

Use Environment Variables instead

Environment Variables is a Power Platform feature that can be referenced in Power Apps and Power Automate cloud flows. They allow you to store and manage multiple values that can be used within your cloud flows as dynamic content inputs.

For reusable URL inputs, this is where Environment Variables are used rather than hard coding your URLs.

They enable you to move your configuration data from one environment to another with solutions.
If the value is different in another environment, simply change it one place in the Environment Variable.

These are two of many reasons as to why Environment Variables are useful when you need to dynamically create a URL for Dataverse or Dynamics 365 in your cloud flows.

In this WTF episode I share how you can use Environment Variables to build a URL to open forms and views in model-driven apps with the help of Power Automate cloud flows.

Model-driven app URL deconstructed

Let’s breakdown what parameters are used in a model-driven app URL.

For forms

URL for a form when using the appname query parameter. This is used in this WTF episode.

1. The Organisation URI which is the Dataverse or Dynamics 365 environment organization URL.

2. To open a specific model-driven app, use the query parameter of either appid or appname.

URL for a form when using the appid query parameter.

The appid is the ID of the app.

The appname is the Unique Name of the app. This is defined when the model-driven app is created and you can find it in the settings of the app.

You can use either as the query parameter however please note that when using the appid query parameter, the value will need to be updated in the environment variable with the ID in the target Dataverse or Dynamics 365 environment after deploying the solution with the environment variable. This is because the ID will be unique in each Dataverse environment.

For this reason, I’ll stick with appname as the query parameter and the uniquename value will be used in my URL. The appname remains the same in each Dataverse environment.

3. The value of the appid or appname query parameter.

The easiest way to retrieve these values is to query the Dataverse web API by using the following GET request.

[Organization URI]/api/data/v9.2/appmodules?$select=name,appmoduleid,uniquename

You can perform this request directly in your browser and the values for the appid and appname parameters will display in the response. Note: based on your signed in user account, you will only see apps you have access to as defined by your security role.

In this WTF episode, I will be using appname as the query parameter.

4. The pagetype query parameter which defines whether to load a form for a row in a table, or a view of a table. For a form, the pagetype query parameter value is entityrecord.

5. The query parameter of etn which is the logical name of the table.

You can find this by browsing to make.powerapps.com, view the table in your solution, navigate to Tools under Table properties and select copy logical name. The copied value can then be pasted into a current value of an environment variable.

6. The GUID of the row in Dataverse or Dynamics 365. If you’re opening a form, the query parameter of id is required which is the GUID of the row in Dataverse.

7. An optional query parameter is the formid of the form in the scenario where you have more than one form for the table.

This can be found in the Form configuration settings within the table in a solution.

For this WTF episode, there’s only one main form for the Challenges table so I won’t be providing this parameter value.

For views

If you’re opening a view, the difference is that for number 4, the pagetype query parameter value will be entitylist.

For number 6, there’s the query parameter of viewid which will be the id of the view.

You can find this by navigating to the view in the model-driven app and copy the viewid value in the URL.

And lastly number 7, the viewType query parameter defines the type of view to open. The parameter value can either be 1039 for a system view or 4230 for a personal view.

Create environment variables in a solution

Now that we know the different components of the model-driven app URL, I'll next share how to create environment variables in a solution.

In a solution, create four new Environment Variables where the data type is text and the values are stored as a Current Value.

1. Organisation URI

The first environment variables is for the Organisation URI. To create an environment variable in your solution,

Click New and select more and then select Environment Variable.
Enter a Name for the Environment Variable and a description.
In the Data Type dropdown field, select Text.
Next add a current value which will be the Dataverse or Dynamics 365 environment URL.
Then click Save. The environment variable is now created.

2. appname query parameter value

The second environment variable is for the appname parameter value with a current value of the appname for the model-driven app. In my use case it's the Innovation Challenges model-driven app.

As a reminder, for this WTF I am using the uniquename value of the app which you can find through the GET API request I shared with you earlier in this blog post.

3. etn query parameter value

This is the logical name of the table. In my use case it's the Challenges table.

This will be the copied value from the table properties I shared with you earlier in this blog post.

4. viewid query parameter value

This is the id of the view. In my use case it's the Active Challenges system view.

🗒️Side note: use default or current value?

Some of you may be wondering, which method to use for storing a value in Environment Variables - Default or Current Value? 🤔

Here's a great discussion thread with Kent Weare and Microsoft MVP Tomasz Poszytek.

In my experience, current value has been used in projects because before Environment Variables came along, us consultants (or implementors - whatever you want to call us 😉) have become accustomed to having variables as "configuration records" with the value (such as GUID of a row) in target environments. The concept of a default value didn't exist beforehand and is different to the deployment pattern we've followed as part of solution deployment.

However there's nothing wrong in using the default value field in the Production/Live environment or using it across several environments AS LONG as the value is the SAME across all environment.

Please also keep in mind that each time you perform an export of a solution with the environment variables from a source environment (such as Development environment), you do need to remove the current value from the solution first. So this would be a pre-deployment task.

Build the URL in a cloud flow to open a form

The use case is when a new challenge is created in Dataverse, post a notification in the app and post message to a channel in Microsoft Teams that allows the user to view the newly created challenge record in the model-driven app or the active challenges system view.

In my cloud flow I have the add a new row Dataverse action for the Notifications table to create the in-app notification and I’m referencing the environment variables in the URLs for the actions. If you want to know how to create in-app notifications, refer to this WTF episode.

The other action is the Post a message to a channel in Microsoft Teams which has two hyperlinks, view challenge and view active challenges. When a user clicks on either of the hyperlinks, it will open the form or the system view based on the URLs. I'll next cover through the steps on how to build the URLs using the environment variables.

In the Microsoft Teams action, select the edit HTML button. This will switch it to the HTML editor.

For the View Challenge hyperlink, I’ll replace the placeholder URL value and build the URL using environment variables, followed by selecting the Dataverse environment URL environment variable.

Then select the Innovation Challenge app environment variable for the appname query parameter.

Next, enter the pagetype query parameter of entityrecord, followed by the Challenges logical name environment variable for the etn query parameter.

Finally, select Challenge as dynamic content from the trigger for the value of the id parameter. This will be the GUID of the row created.

Build the URL in a cloud flow to open a view

The first two steps are the same building a model-driven app view URL, the differences are

the pagetype query parameter is entitylist
the viewid query parameter is required which is the id of the view
the viewtype query parameter which is the definition of the view - either a system view which is 1039 or a personal view which is 4230

Save the cloud flow and it's ready to be triggered.

Demo

To trigger the cloud flow, I create a new row/record for Challenges in the Innovation Challenge model-driven app.

The in-app notification will appear in the model-driven app, and the hyperlinks when clicked on will direct the user to the Challenge form to view the newly created Challenge, or the Active Challenges system view.

The same experience is encountered when viewing the message posted in the Microsoft Teams channel.

Summary

Environment Variables are incredibly useful for automating processes where you need to build URLs through out your cloud flows to open a specific form or view to enter or update data in your model-driven apps. Create them once, and reference it anywhere in a cloud flow. However you do need to remember the following when using Environment Variables:

Add a current value in the target environment after deploying the solution
Remove the current values from Environment Variables prior to deploying the solution

Stay tuned for the next WTF episode as I'll share how to build URLs in Power Apps Cards - the next evolutionary step for "adaptive cards" 😎

Benitez Here.

Wednesday, 12 April 2023

Open forms and views in model-driven apps with Environment Variables and Power Automate