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

With the introduction of Microsoft Flow, Dynamics consultant are relying less on the conventional workflow engine and focusing more on Microsoft Flow and Logic Apps. Eventually, we will see the old workflows deprecated with Flow taking over.
MS Flow is the tool D365 has been missing for a while. It significantly improves the platforms automation and cross platform integration capabilities. What used to be a code only solution is now a point-and-click citizen developer out-of-the-box capability.

As great as it might sound, the more I use Flow with Dynamics 365 CE the more I realize it is lacking in documentation and sometimes still requires coding knowledge (carving REST requests, query strings, payloads, etc.).

To help me remember the gotchas and help others get over their hurdles I will document my MS Dynamics Flow chronicles. I aim to create a reference repository of how-tos and the aim is to address 100 common Flow scenarios in the enterprise space.

 

 

 

 

 

 

It is 6am in Wellington, and after a fright of not having an ESTA visa to enter the US, here I am waiting to start the first leg of my journey to Redmond, WA where the MVP summit is hosted.

I am looking forward to meeting the MVP heroes that I’ve been look up to since I started my career.