In my previous blog post I started making an embedded canvas app to replace dialogs. I started off by creating the app, the screen, some basic navigation and the form. Finally, I added patch logic to save the screen. If you have not read part 1, do not worry this video shows the functionality. The patch logic shows the Relate function, which is very useful, so I would recommend to check that first.
In this post I want to focus on setting the owner of the task. Setting the owner of the task is important because this allows us to distribute tasks to teams or individuals. An entire team could then process the task assigned to them and work them to completion. In this case the credit check that the finance team has to perform will help us resolve the case.
I wasn’t able to set the owner of the task using standard functionality. The PowerApps CDS connector does not allow for updating the owner field. Neither does the Relate function work after the record is created. But of course I have a solution, we can create a synchronous Flow!
Polymorphic what?
First a small lecture on the Common Data Service (CDS). Several field types are available in the Common Data Service. I’m not sure if it is unique to CDS but foreign key fields in CDS can be of multiple types. These are called polymorphic fields. In the owner field for example, you can enter both a team or a systemuser. Benefits of this construction is a denser data model. And in a quick glance the forms and views are easier to understand.
Other examples of polymorphic fields are the “Customer” field type, which can be either an account or a contact. The “PartyList” fieldtype, used in e-mails in the “To” and “cc” fields. And the “Regarding” field type used in activities.
Speaking of activities, our next lesson is about the activities inside CDS. Activity entities have a lot of use cases so it is important to understand them.
“An activity is any action which can be entered on a calendar and has time dimensions”.
The activity entity is the basis of our task entity. Other notable activity entities are: E-mail, Appointment and Phone Call.
You can even create your own custom activity. The task entity I use in the example shares a lot of attributes with other activities. But even though they use the same attributes, you can still change their meta data, like the label or required, individually.
The Flow
Enough with the lessons, on to the Flow! Again, I want to assign ownership of the task to the “Finance team”. To do so we can create a Flow, the Microsoft Flow CDS connector does allow updating the ownership.
Let’s break it down. I created this flow from within PowerApps. So the trigger option is PowerApps.
To run our flow we need values from the Canvas App. Via “Ask in PowerApps” Flow creates a variable which must be entered within our Canvas App.
Flow creates the name of the “Ask in PowerApps” variables by looking at the Action name. You cannot rename these. Therefore, I prefer to create my own variables in Flow to “Ask in PowerApps”. Examples of this are “Set TaskId” and “Set TeamName”. This results in the following help page when selecting the flow:
Following this, we retrieve the team we want to select as the owner by using the variable TeamName. I do not use hardcoded ids as you want to make sure your app works in other environments, especially in Develop, Acceptance and Production streets. Because guids of entities are usually not the same across environments.
This action will return a list of teams. Of course I am sure there is only one “Finance team”, but the system does not know this and will return a list. So, I parse the first result of this list and select the id of the record.
With the id we can now update the task. A simple update action with the TaskId from the Canvas App and set the owner to the id we just selected. Do not forget to set the Owner Type to “Teams”.
Synchronous Flow
While developing this Canvas App I found out there is a way to wait for your Flow call to finish inside your Canvas App! I wanted the best possible user experience and thus all our record creation and record updates haves to finish before we refresh the host form. I dreaded the functionality I had to implement to make this work. First, some ugly timer functions to delay refreshes of the host form crossed my mind. Second, I thought of a weird construct by catching and monitoring a return value from the Flow to see if it finished.
Luckily, while building the second option I found out this was not needed. Because when using the Flow action “Respond to PowerApps” and catching this value inside our Canvas App, the Canvas App will wait for the Flow to finish. As a result we make the Flow synchronous.
Closing thoughts
While some might think that using Flow to fill a gap in functionality of the Canvas App CDS connector is a work around. I prefer to look at it differently. Here we have two new technologies, enriching our lives as consultants, complementing each other. Whenever one does not do what we want, you can be creative and still get the functionality you need. Even when all low code options do not help you, there are still Azure components to fall back on.
As my blog post is already lengthy, I will leave the default values for the next chapter. I plan to implement the OnDataRefresh functionality to make sure the default values are always up to date. So make sure to add me on LinkedIn or Twitter to not miss the next one. Also, if you have any questions, do connect and feel free to ask.
On a more personal level, I am having a blast exploring these options. Stumbling on synchronous Flow functionality while problem solving was especially delightful 😉
I wish you the same fun with the tech and hope you enjoy reading my blog.