D365 CE Flow #1 the one where I monitor children record state and update the parent record

The other day I was interviewing a candidate and I asked them how to update a parent record based on the children’s state? Their answer was “using customisation”…

Jump straight to the steps

Flow is a powerful tool that turns typical customisation into point and click configuration. One of the first scenarios that I came across when using Flow is the ability to monitor the state of related records to a parent and change the parent state once all children meet a criteria.

The Example

As a simplified example, I want to qualify a lead once all associated tasks are marked as complete. In real life, this could be a custom entity or a case but for simplicity an I chose an out of the box example. Nonetheless, in other examples the flow will remain relatively similar.

The Steps

1- Detect a change on a task record (When a record is updated)

2- Initialize an integer variable to count the number of open tasks later.

3- Check that the Regarding record is a lead and that the status reason of the task is completed.

4- Retrieve the top 1 task related to this case that are open. In our case, 1 open task is enough to fail the condition. Your condition may vary.

Your Filter Query may look like the following:

_regardingobjectid_value eq @{triggerBody()?[‘_regardingobjectid_value’]} and statecode eq 0

Consider using Jason Lattimer’s REST builder if you are struggling to create your queryhttps://github.com/jlattimer/CRMRESTBuilder

5- Loop through the records to count them – the logic will loop once or never in our example.

6- If one (or more) are returned cancel the flow. Otherwise qualify the lead by change the original task’s regarding record Status Label to Qualified and Status Reason Label to Qualified – make sure you update the Status as well as the Status Reason otherwise you might end up with a mismatched combination.

Thoughts

Although this flow looks simple a straight forward, it is actually difficult to maintain and is inefficient. As you get more familiar with Microsoft Flow and LogicApps, you will learn to optimise your implementations.

The next post I will target the inefficiencies and address them:

  1. How to trigger the Flow only if the status is changed?
  2. How to avoid those convoluted nested if-else statements?
  3. How to avoid having to loop and count each record?

Stay tuned for more..

All Together

Rami Mounla

2 Comments

  1. Santosh Jahagirdar

    Thanks! Will look forward to this series. Just one suggestion that I learnt recently…the recommendation is to use the Common Data Services trigger and actions instead of Dynamics 365, to the extent possible.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.