The List Records and Apply to Each actions within Flow greatly simplify coding tasks, making Flow highly consultant-friendly.
Originally published in H1 2019 CRMUG Magazine
I have been an enthusiastic User of Microsoft Flow since it was introduced as a beta release several years ago. Microsoft Flow is an online service that automates events (known as workflows) across the most common apps and services. It is an extremely powerful tool that has grown into an enterprise class business solution from its early days when it was positioned as a personal productivity tool. If you aren’t experienced with Microsoft Flow, you can dip your toe into the water by creating a free account.
Flow is already the successor to the SharePoint workflow engine and will be the workflow engine of choice for asynchronous workflows on the Microsoft Dynamics 365 for Customer Engagement platform. Flow is built on a highly scalable technology: Azure Logic Apps. There are a lot of additional reasons why it is superior to the traditional workflow engine with its Flow Checker, run history, analytics, rich connectivity to 225+ services, and visual designer as examples.
But there is one capability that Flow brings to the table that absolutely makes it the tool of choice for functional consultants: List Records and Apply to Each. These two Flow actions literally take the need out of many business requirements from being a developer-required coding task to making it functional (citizen developer) consultant-friendly. When you use these two actions together, you can loop through child records and perform a wide range of actions on the child records.
Consider the business scenario where you are updating an Account record from a backoffice ERP system that can change the status of the relationship from prospect to customer or ex-customer. Once the Account record is updated, then you want to reflect the same status on the child Contact records.
Let’s take a look at the design pattern and dissect the components.
In Figure 1, we look at the basic pattern in a high-level view. The first element is the Triggering event. In this example, the Trigger is when a record is updated. This is the most likely Trigger event that would use the List-Apply pattern since the presumption is that a parent record already exists with child records. This Trigger can be applied to just about any Common Data Service entity that exists—out of the box or custom. For this illustration, we are running it against the Account entity.
In Figure 2, we want the action to return all the child records whose parent is the Account record from the Trigger action. In order to do this, we need to create a
filter so that the child Contact records that are returned in the list are the ones where the lookup to the parent Account is equal to the unique ID of the parent Account from the previous step. The _parentcustomerid_value returns the unique ID of the lookup and not the human readable Account name. It is then set to compare using the equal expression to match the Accountid from the previous step. If we look at the full expression behind the citizen developer friendly version, it would look like this: _parentcustomerid_value eq @{TriggerBody()[‘Accountid’]}.
To continue to build the Flow, the next step as shown in Figure 3 is to select apply to each, which is a control action. This will set up the basis of the process to loop through all the records that were returned by the previous list records action.
In Figure 4, we can finish the design pattern to insert the dynamic content – ‘Value’. This is essentially the output of the preceding action list of records. The code that is behind the dynamic content is as follows: @body(‘List_records’)?[‘value’]. Once we establish the looping with the apply to each, there needs to be an action inside of the loop.
In Figure 5, the action is to perform an update of all the child Contact records returned by the list of records. We use a custom global option set value for customer status from the Account record and then update the Contact with the same value.
At our company website, we have several blog posting examples of complete Flow solutions that use this design pattern, including “How to Use Flow to Copy a Qualified Lead’s Notes to the New Opportunity”. Another interesting use of this design pattern is to use it to loop through list members of a marketing list to send each Contact an SMS message.
The List Records—Apply to Each design pattern is a function that can be used in many different ways with the Microsoft Dynamics 365 for Customer Engagement application. It is only limited by your imagination and the business requirements of the organization.
Go run with Flow!