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.
If you are building Model Driven Apps, you would have realised by now that Unified Interface is the future. Microsoft has made huge investments in this area to ensure that you have an optimal experience regardless of the device or form factor. Unified Interface is composed of several components/controls that help you to visualise and interact with the data.
If you wanted to swap out the control or build a new one that is better than what comes out this box, the only way you could do this earlier was to build a custom webresource and embed it into an IFrame. Using IFrame is clunky, and you had to handle all the complexities of building a responsive interface. IFrame also cannot be displayed on a view, only on a form.
But with the arrival of PowerApps Component Framework, you can build custom components/controls that can be used in fields or view fairly quickly. PCF entered public preview around April, 2019. The are three things that you will be using while developing a custom components/control: PCF, the framework that can be used to build the components, a CLI (similar to yeoman, if you are from node world) that is used to scaffold, build & deploy the control and a test harness to assist you during development.
What do you need to know to build components/controls using PCF
Ability to run commands from commandline
If you don’t like to live in the commandline, download XrmToolBox tool called PCF Custom Control Builder by Danish
Office UI Fabric (preferable)
Edge Dev Tools or Chrome Dev Tools (while build/debug)
Fiddler (while build/debug)
Where do I go to get inspired or assess the capabilities
After you have downloaded and installed the managed solution, you can add the PCF component/control to an existing view or new view.
As you can see above, I am configuring the view to show the results using “Cards” control, and not “Read only Grid” control. After this you need to configure each property to the correct field on the entity, that you would like be shown on the card.
Each property on this control maps to the card as below
How do you get the image to display on the custom control?
If you don’t need image on the card, you can skip this step. This is the tricky bit. There is a field on each entity that is capable of storing a image. The name of the field is entityimage. This screenshot should jot your memory.
You cannot however, add the entityimage field to a view, as this field is not visible in the View Builder: both classic experience and maker experience. But, entityimage is a valid field, so you can add this field using the awesome tool called “View Designer” in XrmToolBox.
This allows you to modify both the FetchXML and LayoutXML of the view. Using this tool you can add the “entityimage” field.
Once you do this, you can see the entityimage field on the view in the classic designer. If you try to open the same view in the modern designer it will fail.
After save and publish, you should now be able to use the custom control on the view that it is bound to. You can also use a custom control to display results on the Quick Find as well, using similar update to FetchXML and LayoutXML, but Quick Find does not seem to be supporting entityimage attribute at the moment.
TIL: It is possible to render QuickFind results using PCF by using API to modify SavedQuery’s LayoutXml. Not sure why this is not enabled on the UI yet.
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.
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 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.
The inspiration for this post is this post from Geetha -> https://svaghub.wordpress.com/2018/11/03/role-based-security-in-powerapps-using-spgroups/. The idea is to basically use Flow to check what kind of permission the current user has, so that some functionalities can either be lit up or hidden in the canvas app. In her post, Geetha was using SharePoint user group to get this information. Being from a CRM background, I want this to be retrieved from CDS + I am not a big fan of SharePoint.
Attempt 1: Use DataSourceInfo(‘Users’, DataSourceInfo.CreatePermission), to check if the current user can create Users, which means they are Sys Admin. But, there seems to be a limitation on DataSourceInfo, which means it does not return the correct permissions for CDS entities. It always returns true, which is not correct. So, this attempt was not successful. This would have so much easier if it had worked, as all the logic would be entirely in the canvas app.
Attempt 2: Flow magic. I didn’t want to head this route, but since DataSourceInfo did not work, I had to use Flow to solve the problem. Solution is one of the restricted CDS entities. Only certain roles have access to read this entity OOB. Below are those roles.
So, I am using this as the flag to show or hide canvas apps controls. Below is my Flow.
There are two parallel branches, one if there is an exception while retrieving Solution records, which means that the user cannot read “Solution” entity and another branch if they have read privilege on “Solution” entity. Depending on which branch the Flow takes, “canread” can be true or false. I can use the result to show or hide controls on the canvas app. The two branches have the appropriate “configure run after” set.
The clunky bit about this, which I don’t like is that fact that Flow will report that the execution has failed, when Flow takes the “Cannot read Solutions” branch.
In the programming world, handling an exception appropriately and continuing like nothing happened, is not considered a failure, but it looks like Flow has a different opinion on this.
Potential improvement to the design: Create a new CDS entity called “Canvas App Permission” and create attributes on this entity, to manage which areas in Canvas App should be shown or hidden. Create multiple records of this new entity and assign this to teams or individual users, depending on how you want the permissions to be applied in canvas apps. The Flow can then retrieve this entity, and PowerApps can use this result of the Flow to hide/show areas or functionality.
Hope this is useful. Credit to Geetha for coming up with the original idea.
Over the past few weeks, people have been demonstrating some cool games, built entirely using PowerApps. The reason being, that there was a contest from ThoseDynamicsGuys. If you are interested in finding out about some interesting games from this contest, watch this video from Mr.Dang himself -> https://www.youtube.com/watch?v=0-ZWqs_emQA where he reviews the games.
There were some apps that caught my eye during this period:
I was especially fascinated by what Scott and Makato accomplished with the side scrolling nature of the games, how Geetha managed to rotate the roulette as there is no rotate angle property on images and how Nagao managed to calculate the trajectory and resistance of the ball. The first step to learning is to understand how other people do it, so I spend 4-5 days to understand how these apps have been developed.
I then wanted to develop something of my own, using the concepts that I had learnt. Spirograph was the first thing that I thought of. The easiest part was to get the equations to calculate x and y. I had to then learn the basics of starting and stopping a timer, and how to create a sense that the pattern was being “drawn”.
Since image control can render SVG, I decided to try this approach. My first challenge was how do I calculate the x and y on every tick of the timer. So, I decided to follow the approach demonstrated by Brian Dang, that involve checking and un-checking a toggle control.
Every time the toggle is checked, I can increment the iterator variable and calculate x and y for the line to be drawn and the string for the SVG path with all the lines. In SVG you can draw a line, by moving to a location specifying Mxy and then drawing the line using Lxy. Below is the formula in the OnCheck event of the slider
I can then simply set the SVG path’s d property from the PathVar variable, that has all the line co-ordinates. Below is the value for the Image property of the Image control that renders the Spirograph.
Below a video of the app in action. You can play around with the sliders and be fascinated by the patterns that it generates.
Here are some interesting patterns the app generated.
I have been looking into scenarios with PowerApps and Flow that can benefit Dynamics 365 Customer Engagement user experience. One of the scenarios that can add value right away is on the entity forms. PowerApps can be embedded as an IFrame on the normal entity forms, and can be used similar to Dialogs to offload some processing to PowerApps and Flow.
Here is the finished product.
No scripts are needed on the form to embed the PowerApp.
Once PowerApps is in place, the current form context can be inferred using the “id” parameter that is passed on to the form.
I use a known Guid during the design phase to assist me with the app design process, as the PowerApps calls the Flow during the OnStart event and sets the ProblemDetails variable.
A Flow can be associated to an event, from the Action->Flows area.
When the PowerApps loads, it calls the Flow with the Guid, to retrieve the case details. The Flow that responds to PowerApps with these details on the case: Title, Customer Name, Type of Customer (Account or Contact).
In this Flow I just use “Respond to PowerApps”action and return the three outputs.
I used variables to store the Client, which could be the Account’s name or Contact’s FullName, depending on what is on the case. The client type could be either Account or Contact. Account Details and Contact details are retrieved based on the result of the Client Type branch.
For the second Flow, the user presses the “Check” button which performs some additional checks based on business criteria. For this Flow, I used the “Response” action, which allows me to return JSON results. I stored the cases I am interested in on an array variable.
From the variable, I used Select action to grab only the properties I am interested in.
I can then use the “Response” action to return these to PowerApps.
One weird thing that I encountered in PowerApps/Flow integration, is that I would simply see the result as “True” from Flow, when I tried to return the return the response straight from the variable.
When I used Parse JSON and then Select to reduce the properties it started working. This can happen when there is something wrong with the schema validation, but I am not sure how this can happen when I copy-paste the JSON response from the previous steps to auto-generate the schema.
One more thing: When the Flow that is associated with the PowerApps changes, just make sure to disassociate and reassociate the Flow. I had issues when I did not do this, due to PowerApps caching the Flow definition.