Main Form Dialog is a new feature in model-driven Power Apps. It was officially released this month (Feb 2020). Along with this, I also noticed today that Microsoft has also quietly added a new event that plays nice with MFD.
The new event is called OnLookupTagClick. This event handler can be used in scenarios where the user clicks on the lookup. Normally, this would redirect the page to the lookup record, but you can block this navigation on OnLookupTagClick, and rather show the lookup record on a modal popup using navigateTo. Below is the sample code on how to do this. Since I ran the code from DevTools console, I am using the deprecated Xrm.Page. If you are running this from a form, you should use the formContext.
Early Bound generator is a great XrmToolBox tool developed by fellow MVP Daryl LaBar. It helps you to generate the strongly-typed classes that can be used in your custom code development projects e.g. plugins, workflows, console app etc. If your are committing the early bound classes into source control, you also should committing the configuration that is used to generate the classes and also make it easy for the next developer joining the team to generate these classes, without jumping into XrmToolBox and clicking it manually. In this post, I will present my approach into streamlining this process.
Generate the files once from XrmToolBox with the settings that are optimal for your requirements
Locate the the path where all XrmToolBox tools are installed. You can see this by clicking Configuration -> Settings. On the settings page, click on the “Paths” tab and then the “Open XrmToolBox storage folder” link.
Navigate to Plugins -> DLaB.EarlyBoundGenerator
Copy the crmsvcutil.exe.config file into a folder. You would need this for checking in into source control. This file won’t have any passwords, so it is safe to check in.
Below is the PowerShell script to run. You also should committing this script into source control. The PowerShell script should be run on the same location where you copied the crmsvcutil.exe.config file in the previous step. The generated early bound classes will be in the folder specified in the “$outputPath” variable, which is “EarlyBoundClasses” in this script. You can change this match your solution folder structure.
Microsoft also has created a AppId and RedirectUri that you can use on you development or test instance. Below is the disclaimer on the docs page about these.
When using the OAuth AuthType\AuthenticationType
For development and prototyping purposes we have provided the following AppId or ClientId and Redirect URI for use in OAuth Flows.
For production use, you should create an AppId or ClientId that is specific to your tenant in the Azure Management portal.
Sample AppId or ClientId = 51f81489-12ee-4a9e-aaae-a2591f45987d
Sample RedirectUri = app://58145B91-0C36-4500-8554-080854F2AC97
User Settings utility is a popular XrmToolBox tool that helps administrators update the user specific settings in bulk, without asking individual users to update them. Here is how it looks:
I attempted to do this using embedded canvas apps. Here is how it looks:
As you can see the canvas app is embedded inside the “Business Unit” form called “Business Unit – Users”. It initially displays a list of users in the Gallery. You can then click on an user record to edit the user’s settings.
The canvas app currently uses the ModelDrivenFormIntegration datasource, that is the default for embedded canvas app. But, you could very well tweak this app to make it a regular canvas app, and then you would be able to edit the user settings from your phone on the go, which could be quite useful for an administrator.
There are couple of ways to gets entity record counts: you could use XrmToolBox’s Record Counter Tool, or write the FetchXml to count the records as you navigate from one page to the next. But, if you just want to use the SDK here is a simple method: a new message called RetrieveTotalRecordCountRequest. Here is how to use it in C#:
var r = new RetrieveTotalRecordCountRequest();
r.EntityNames = new[] {
"contact", "account"
};
var m = ((RetrieveTotalRecordCountResponse)this.Execute(r)).EntityRecordCountCollection;
m.Dump();
I recently came back from Sydney and I now have 4 new Opal cards. Opal card is used in public transport across Sydney and these cards use NFC technology. Since I no longer have any use for these cards in Melbourne, I wanted to do some thing productive with these cards. I also wanted to try a low cost alternative for triggering Flow from a hardware that is not flic (Opal cards are free).
Reading NFC card is not a native functionality of Flow, so I decide to use something that is capable of reading NFC card and also can call a HTTP endpoint. Since I am using Android, there is an app that meets this need perfectly. It is called Automate. This app has been around for a while, and you can develop Automate Flows that can use native hardware capability of Android.
Here is how my Flow looks in Automate.
The are start important blocks to get this Automate Flow working:
Read NFC block is used to read the NFC card. I map the NFC tag id to the variable called “TagId”. You can use the “Read tag” button in this to identify the NFC tagid and then use it in the switch/case statements in Microsoft Flow.
The next step in the one where I call Microsoft Flow, which is triggered by HTTP Request.
The same Automate Flow has to be triggered again after Microsoft Flow is called using HTTP Request, so that a new fiber is started to continue reading the NFC card.
This is the Microsoft Flow that is triggered by HTTP request.
The HTTP trigger accepts the tagId in the URL parameter of the HTTP Request.
Based on what tag has been scanned, I can then perform the appropriate action. I use the switch statement for this purpose.
Here is a quick demo of Automate and Flow working together in harmony.
Here are somethings that are now possible with the NFC capability:
Deploy solution from DEV to TEST, using Azure Function, PowerShell and Xrm.Data.PowerShell module. I experimented with this and it works nicely even though PowerShell support in Azure Function is only experimental
Call a RunBook in Azure Automate using HTTP Webhook
I hope this is useful in scenarios where you need alternate ways to trigger Microsoft Flow.
I have a Flow that sends out email at 8 a.m everyday that lists the solutions that were imported in the past 24 hours. In the initial version of the Flow, the email was missing an link to the actual solution. But, after making some changes, the email now includes a clickable link to the solution that was imported.
As you can see there is a link in the last column. This link is not hardcoded. The base URL changes, based on the CDS environment the Flow is deployed to. The trick is to grab this URL from the “List records” action which includes the full URL to each record in the result. You just need the first record in the result set to use in the expression in the next step.
As you can see the @odata.id key contains the full URL to the record, from which you just need the base URL. Once you grab the base URL, you can easily compose the full URLs to the areas that you want the link to navigate to e.g. open the record, open solution, new record, open list etc.
Below is the expression that I use to get the base URL only.
Solution is a feature that has been used in the CRM space for a long time. Solutions support for Flow was announced last year -> https://flow.microsoft.com/en-us/blog/solutions-in-microsoft-flow/. One thing the post does not mention is that Flows have to be created from the solution record. If you have an existing Flow, that you want to package up into a solution, you cannot do that. To workaround this limitation, I have created a Flow to clone an exisiting Flow and make it solution enabled.
The Flow itself it not that long. Here is how it looks.
The Flow definition fits on a readable screenshot!
The first step is to select the existing Flow that you want to clone, into a solution enabled Flow. This can be done using the Flow Management Connector’s “Get Flow” action.
Solution enabled Flows, like solution enabled canvas apps, are also stored in the CDS database. The entity it used to store the Flow is called Process (logical name: workflow). It stores both the Flow definition, as well the the connection references.
However, the connection references are stored differently between CDS and Flow. Here is how the connections are stored in Flow.
As you can see one is an array and another is an object. So, this means the connection JSON has to be reshaped, when we create a Modern Flow Process record, directly in CDS. We will use select action to reshape the data, and then do a replace to cleanup the JSON.
The action below is the one that creates the Solution enabled Flow. You create the “Process” record using the CDS connection, and populate the Flow JSON in “Client Data” field.
This creates the JSON that is accepted for the “Modern Flow” process record.
In the last step we activate (start) the newly created Flow.
The Flow’s GUID is stored in a field called “workflowidunique” on the Process entity. So, we can use this to the retrieve the Flow, and activate it.
The crazy part of this Flow is that I was able to run the Flow on itself and add it to the solution, hence the title of the post.
You can now add the Flow into the Solution, from web.powerapps.com
The newly created Flow, will have the same step Flow name, you specific in the first Get Flow step, prefixed with “Solution: “
The solution with the Flow can now be exported and imported into a new CDS environment. I hope this helps you to package some of you old Flows into a solution. This Flow can further improved by listing all Flows in the environment and doing the same process or cloning it, rather than specifying a specific Flow at design time.
