Microsoft Power Automate (previously called Microsoft Flow) is an awesome tool to automate a lot of processes in your work environment. Microsoft Dynamics 365 is headed to adopting Microsoft Power Automate as its main workflow engine. The PowerApps platform, with its numerous available Power Automate connectors, is empowering its developers a richer set of tools to do a lot of cool things. This blog will cover some gotchas as you start to create your own set of Child Flow called from a parent Flow.
Note that the Flow behaviours in this blog were observed as of when this blog is written. This could be subject to change with future Microsoft updates.
Scenario
For this blog, we will have the parent Flow called “Process new Account”, which is triggered on create of a new Account. The parent Flow calls a Child Flow called “Create Primary Contact (child Flow)”. The child Flow creates a Contact record, and associates it to the Account with the Primary Contact lookup field.
Can Only Create a Child Flow From a Solution
Before you start making a Child Flow, what you need to know is that you need to create a Flow from a solution. The correct set of Common Data Service (CDS) connectors (the ‘CDS (current environment)’ connectors discussed later in the blog) is only available from a Flow within a solution. Best way to create a Flow in your Dynamics 365 solution is to go to: www.make.powerapps.com. In the left pane, click Solutions and select the solution you want to package your Flow under. Then click New > Flow to create your Flow under that selected solution.
I’ve tried accessing the ‘CDS (current environment)’ connectors from a User / Team Flow, and these set of connectors are not available here.
Power Apps Trigger and Passing Parameters
The first thing to note is that a Child Flow can only be made from a solution Flow if it has a PowerApps trigger.
What is great about this trigger is that you can define some parameters to be passed into the Child Flow from the parent Flow that calls it.
So with our scenario, what if we want to pass in the Account Name from the parent Flow into the Child Flow, and populate the Account Name into the Contact Last Name? We can select the “Ask in PowerApps” dynamic content option on the Contact Last Name field:
It will immediately populate the Last Name field with a dynamic content.
So if we go back to the Parent Account, on the “Run Child Flow” action step, we can now see the new parameter that we generated above. You will notice the parameter name is named the Flow step name and the Flow field name.
Note that if you’re passing in multiple parameters from the same kind of action connectors, it might be better for you to rename each Flow step uniquely. This is so that you can distinguish each unique parameter, and pass in the correct value. If I didn’t rename my step from “Create a new record” to “Create new Primary Contact record”, it would have automatically passed in the default CDS connector name “Createanewrecord_LastName”. This will be problematic if you have multiple ‘Create a new record’ steps in this case.
For example, if you have 2 CDS actions to create a record, flow will automatically name these as “Create a new record” and “Create a new record 2”. Flow has rules such that each step name must have a unique name. But if you’re passing a parameter for each of these (shown below), it can be hard to tell which one is which, and you may pass in an incorrect value. I recommend renaming your steps not only to avoid mistakes, but also for easier readability.
The “Common Data Service (current environment)” Connector
The main differences with creating a Child Flow is that it uses a special set of Common Data Service (CDS) connectors. While I was used to using the normal CDS (with similarities to the Dynamics 365) connectors, you can only use the connectors from the “Common Data Service (current environment)” set within a child Flow. Note the difference from the normal CDS connectors is that it has ‘current environment’. This can be confusing, especially if its your first time making a Child Flow.
Ensuring you have the correct connectors will save you from having to re-do your Flow because you did not use the correct connector set.
Having the incorrect CDS will result in an error:
“Could not find property 'headers.X-MS-APIM-Tokens' in the trigger outputs. Workflow has connection references '[\"shared_commondataservice\"]'…”
This applies with using the Dynamics 365 connector, and will result in an error:
“Could not find property 'headers.X-MS-APIM-Tokens' in the trigger outputs. Workflow has connection references '[\"shared_dynamicscrmonline\"]'…”
You can also observe in the screenshots above that the incorrect type of CDS (or Dynamics 365) connector has an Environment (or Organization Name) drop down field. Even selecting “Current” will still give you an error. The correct “CDS (current environment)” connector does not give you an option to select the connection Environment or Organization instance.
To be sure, when searching for the CDS connector, you can hover your mouse to make sure it has ‘current environment’ to avoid confusion between the two types of CDS connectors.
You will also notice ‘current environment’ on the CDS action connectors once you click it.
Setting Entity References
In our child Flow, the next step is for us to associate the created Contact record to the Account record. With the normal CDS or Dynamics 365 action step configuration, you simply just plug in the GUID dynamic content into the field. Easy as that right?
Well, the “CDS (current environment)” action won’t like this. In your parent Flow, you will get the error: “Encountered internal server error from Azure Resource Manager…”.
This will result in an error: “Resource not found for the segment…” on your child Flow.
What you need to do now is to Turn Off the child Flow because the Azure Resource Manager will re-attempt to reload the Flow by firing the same flow run multiple times.
Probably the biggest difference between the normal CDS and the “CDS (current environment)” connector action is how to configure the action steps to set entity reference links.
What the “CDS (current environment)” action is expecting in the entity reference link is an ‘entity set and key’ semantic. We know the entity set also as the plural name of an entity, e.g. for the “contact” entity, its entity set its called “contacts” (note the case sensitivity of this aka not capitalized). If you’ve done Javascript development in Dynamics 365, this is the same as to setting an odatabind in the Xrm WebApi for the lookup field.
You can test this out yourself. For this example, if we just plug-in any text value, e.g. the text valued I’ve plugged in is the entityset name without the key called “contacts()”, the flow action will return with the error: “The supplied reference link -- contacts() -- is invalid. Expecting a reference link of the form /entityset(key).”
With this information, to set the entity reference link using the “CDS (current environment)” action, have the entity set name and the Contact GUID dynamic content within enclosing brackets, e.g. contacts(GUID) as shown below.
Something to note is that the connector action also labels the lookup field with the entity set name (highlighted above, the Primary Contact lookup field has the ‘Contacts’ entity set name labelled in the action). So if you’re worried about what is the correct entity set name for your entity reference links, the action will usually put it beside the field name. To always be sure, always check the entity schema and plural names within your Dynamics 365 instance.
With Customer lookup fields (that have entity reference links to either Account or Contact), the “CDS (current environment)” action will have 2 fields for each different entity type. So its important that you pass in the correct entity set and the correct GUID to the correct entity type field.
Returning a Response
The last step in creating your child Flow is adding a response action. Flow won’t allow you to save your Flow during its validations, with an error: “…<flow name> cannot be used as a child workflow because it is missing a response action”.
This is to ensure that the “Call Child Flow” action step in the parent Flow is processed as successful on the parent Flow’s Flow run. You need to select the “Respond to PowerApp or flow” action connector.
On the response configuration, it can be as simple as a text response. After we’ve created a new Contact record in our Child Flow, we can simply have a response message to say that the Flow has been processed successfully. We can also return the new Contact’s GUID into the response to be used by the parent Flow.
Once you finish your child Flow, run the parent Flow to test, and ensure that it is returning the correct successful response in the output body .
