Cascade from parent to child the flow way

When working with Dynamics 365 CE and designing solutions, it happens from time to time that you want to cascade information from parent records to child records. One example could be to have the address of the contact updated when the address of the parent account is changed.

Please do have in mind that you can you use quick view forms for displaying information from the parent record on a form as well as displaying columns from the parent record in views. Also, do not forget that cascade of ownership and deletion of records can be configured with out of the box (OOTB) functionality, see Entity relationship behaviour.

On the relationship you also have the OOTB functionality to configure mapping between parent and child. However, the child record gets the data from the parent only when created and not when the data is updated on the parent. For more info, see Map entity fields.

I am not a big fan of duplicating data, but sometimes you simply need to do more than what is provided with the OOTB functionality regarding writing data to child records. Last week we needed to create a solution for cascading the status from parent to child, in our case, when an opportunity was set as won, all the child records of a custom entity related to opportunity were to be be deactivated.

I was about to do what I have done before in similar cases, namely create a plugin for cascading from parent to child. However, this time I gave it a try with a very popular and trendy option – I created a Microsoft Flow. 😊 .

Cascade data the flow way

Here follows a description of how to setup a flow for cascading information from parent to child records. In this case when an opportunity is set to won, all child records of a custom entity should be deactivated. When setting this up real environments should be used, this is just an example and that is why no particular environment is specified.

First, here is the overview of the setup:

1. Go to the Maker portal
2. Create a new flow from blank
3. Choose the trigger Common Data Service – When a record is updated
4. Insert a new step – Condition (if you want to cascade based on some condition)
5. For If Yes, add an action, Common Data Service – List records
6. Add an action, Apply to each
7. Add an action, Common Data Service – Update a record

Update 3rd of June 2019: An improvement for Step 5 is to follow a wise advice from the Business Applications MVP, Jonas Rapp – to use guard clause instead of classic IF. Easier to maintain and you get a better overview of the Flow. Read his words about it here.

Now let’s start with the making. Navigate to https://make.powerapps.com

Perhaps now you are thinking – what’s up with the starting point, why not navigate to https://web.powerapps.com. Well, I was told from Microsoft that they are redirecting and changing from web.powerapps.com to make.powerapps.com. Why? Perhaps to confuse us all or is it just a popular thing using the word make? It kind of makes sense though, since it is referred to as “maker portal”. Perhaps there is a better explanation for the change, but then I somehow have missed that part.

Choose Flows in the menu to the left, then choose to create a new flow. Click New, Create from blank and choose to search for a trigger to start with. Since I want to work with the data within the CDS (actually in my case it is a Dynamics 365 CE app, but as you all know, the data is in the CDS), I will use the Common Data Service connector for all of my actions involving data. Choose the trigger When a record is updated.

Select Environment, Entity Name and Scope. If you are familiar with workflows in Dynamics 365 CE then you know that the Scope refers to for which records the flow/workflow should be triggered and this is related to the security model and ownership of records. You can read about it here under Scope. The below text is taken from there.

For user-owned entities, options are Organization, Parent: Child Business Units, Business Unit, or User. For Organization-owned entities the only option is Organization.
If scope is Organization, then the workflow logic can be applied to any record in the organization. Otherwise, the workflow can only be applied to a subset of records that fall within the scope.

Expand Show advanced options and select a field in order to have the flow triggered only when a certain field is updated.

Now you are done with the triggering part. The next step is to add a condition. Because in this particular case, we want an action only when the triggering field has a certain value, i.e. when the Status is Won. In order to be able to set such a condition you will need to have knowledge about how it works with statuses in Dynamics 365 CE, e.g. for an opportunity the values behind Won are Status = 1 and Status Reason = 3.

This is the best documentation I can find from Microsoft regarding listing statuses and status reasons for custom entities in Dynamics 365 CE. It is not for the latest version though, however the codes are the same as in the latest version at least in the Opportunity case.

Then add an action for If Yes, choose to add the action List Records. Choose your environment and then the child entity. In the field Filter Query set an ODATA filter so that you will only retrieve the records that are child records to your parent, i.e. to the record which triggered this flow.

Of course your requirements could differ from this, perhaps you want to cascade data without any condition, e.g. in the case of cascading address info from account to contact, then you can just skip having a condition in your flow.

Next, when using a condition, we want to specify an action, i.e. what should happen when the opportunity is set to won. Add an action for If Yes, choose to add the action List Records. Choose your environment and then the child entity. In the field Filter Query set an ODATA filter so that you will only retrieve the records that are child records to your parent, i.e. to the record which triggered the flow.

Pay attention to the syntax of the filter. The field with the field name myprefix_opportunity_id should be equal to the opportunity which triggered the flow.

Now we have listed the child records to the record that triggered the flow. The next thing to do is to add a new step – Apply to each. Choose Dynamic content for “Select an output from previous steps”, choose Value.

Then add a new action, Update a record, still using the Common Data Service connector. Choose environment, entity to update, i.e. the name of the child entity and choose dynamics content for the input Record identifier. Choose the child entity which will be found under the Apply to each section of the dynamic content.

After you have chosen Choose a record identifier you will be able to choose Show advanced options and in there specify the fields that should be updated on the child records. In my case I wanted the child records to be deactivated, so I chose to set the status and status reason to inactive.

Now you are done with the making. Save and verify the flow. Below you will see an overview of it.

This was actually my first experience with flow! If you want to stick to a no-code approach, using flow is a way to solve how to cascade data from parent to child records.

Now I am looking forward to solving more customer requirements using flow and not only for the cases when you want to do something with the data in the CDS, but also when other data sources should be included as well, since it is for those cases I believe this very popular flow thing becomes powerful for real.