United Kingdom – D365/CRM

Flows in Power Automate – Getting started with Dynamics 365

By Paul McQuillan posted May 07, 2020 06:20 AM


Working with Dynamics 365 many will be comfortable designing Entities and Fields, and then enhancing with Workflow to automate Activities or Data in the solution.

The Workflow Engine in Dynamics 365 has been around for a long while now, dating back to 2005 with v3 of what was then, MSCRM. (before it became Dynamics CRM, then Dynamics 365, and ultimately the Power Platform)

Its still a pretty good engine and has many things to like – but change comes to everything and we are increasingly see Flows or Power Automate become the go-to engine for building business logic and no-code actions.

Whilst the Roadmap for Power Automate will ultimately come to replace traditional Workflow, it is a slightly different beast in integrating many cloud systems together (not just Dynamics) in a no-code but slightly more technical approach.

To review how we might put this into action in our projects, I wanted to look at how we can use a Flow to implement logic that would be impossible using a Workflow; and has been an area of frustration for Functional Consultants since year dot with Dynamics – namely, how to update a bunch of child records from a parent record.

If we look at an example use case for this functionality:

In CRMCS, we track a number of Change Requests as Cases in our internal use of Dynamics.

This way each change can be tracked from Identification, Design, Implementation, UAT and finally Pending Release.

The list of Cases are then bundled together as a Release which is scheduled and then released from Sandbox and into Production.

When this Release has been completed, we then have a problem where each Case needs to be closed individually to confirm that change has now been released into production.

Ideally we do not want to force this admin onto our User, and instead we want each of the linked Cases to be automatically closed.

Historically in Dynamics 365 this would require borrowing a Developer to build a simple Plugin that would run a Bulk Edit or Bulk Status Change for all the Cases linked to that Release – as Dynamics Workflow has always been able to ‘go up’ but not ‘down’ in terms of updating a supporting record via Workflow, hence our need to get into Plugin Development.

Power Automate changes this, as it gives us a new Workflow Engine that is capable of ‘updating down’ as well as the traditional operations within standard Dynamics Workflow.

NOTE: Power Automate’s ‘maiden’ name was Flow before it married into the Power Platform family – and the ‘workflows’ we build here are typically referred to as Flows.

We will use this example to look at an introduction to Power Automate to implement this workflow in Dynamics.

First, we want to access Power Automate in the context of one of our Dynamics or PowerApps Solutions – this is key as it enables the Flow Connector for using the Common Data Service as our Current Environment, and if launched from a Solution, then the Current Environment is our Dynamics 365.

For efficiency wise, using the connector for the current environment saves us having to re-specify which CDS Environment we want our logic communicating with; but more importantly, some features with Dynamics 365 are not available when we build a Flow outside of any solutions.

So don’t do it from here:


Do it from a Solution in Dynamics or PowerApps instead:


This gives us the option for connecting to CDS as our Current Environment:


We will then be presented with our Flow Designer with our very first step to configure.

When a Record is Updated…

This asks us for:

Trigger Condition – which CDS or Dynamics 365 Environment in our Tenant that we want the logic to trigger from.

Entity Name – the Entity in CDS that we want the Update to trigger the logic.

Scope – here we see an option common to Dynamics Workflow in defining the Scope of use for our Flow – be this limited to our User, Business Unit, Hierarchy or across the Organisation.

Advanced Options - Attribute Filters – if we want the Flow to trigger on Update, but only when a particular Field or Fields is being updated.

In my example, I can set this to our Custom ‘Release’ Entity and to only trigger when the main Release Status field is being updated.



Here I only want my logic to update the Cases associated to the Release when the Release is at a Stage of ‘Released’ – so we can add a Condition to fork the logic accordingly.


List Records

If we want our Flow to read and then update a batch of Records, we can then add a Step for List Records.

We can then configure what Records we want to retrieve by configuring the Settings of this Step.

Environment Name – we again pick which CDS or Dynamics Environment we want to return records for.

Entity Name – we then pick which type of records we want to retrieve, in my example, Case Records.

Filter Query – set which Case Records we want to return, in my example, all the Cases linked to this Release – which means we type our condition as: _crmcs_releaseid_value eq <Release>

Note that where we are using Lookup Fields and matching by GUID, we need to use good notation in specifying whether to query on the basis of the name of the record (_name) or the value of the underlying FK or GUID ID. (_value)

This works hand in hand with an underscore before the field name.

So the query we might expect for: crmcs_releaseid eq {GUID}

Would actually be expressed as: _crmcs_releaseid_value eq {GUID}

In my example we would want this condition and a 2nd condition to prevent any Cases that have already been closed from being updated – and so we would have a Filter Query of the following:

_crmcs_releaseid_value eq <<Release>> and statecode eq 0

Select Query – this specifies which Columns about our Case are going to be returned by the query.  For developers used to Dynamics 365 Plugins, this is our Column Set.  Best practise here is to only return the Columns that our logic requires, as this will make our Flow Logic faster (as less data is needing to be exchanged) and also prevent problems if we are then retrieving a wider set of fields and then recommitting those fields in an Update.

The List Records action in Power Automate mirrors the Retrieve Multiple operation in Plugins – the following documentation on the parameters here can be useful when putting the action to use in our Flows: https://docs.microsoft.com/en-us/connectors/commondataserviceforapps/#list-records 

Apply to Each

With the CDS List Records Step in place, we can then add a Step with an inbuilt Flow Control for Apply to Each.

As the name suggests this will loop through each of the retrieved Case Records to apply an action on each.

We can then add an action in this Apply to Each, and in our example, add an action for Update a Record which will update the Case as the current item in the loop.


This sets our logic to update all the Cases associated to the Release that has just been updated.

Here our Update a Record step will pass back the data we retrieved in our List Records Step as the Update Message – this means that any columns we included in our Select Query will be updated in Dynamics. (we will see the full set of columns being updated in the usual Dynamics Audit Log to see the full extent of the update)

This means that keeping to a minimal Column Set in our Select Query will mean a smaller and so easier update back into Dynamics – keeping our Audit Log size down, and more importantly, making our business logic less error prone with the smaller update.


With our core logic built into the Flow, we can tidy up and add steps to show how the Flow finishes when forking to either condition.


This wraps up our logic so we can activate and test within Dynamics 365 or our PowerApps Environment.

Flow Checker

Before we run the Flow in Dynamics, we can use the Flow Checker to review how we have built our Business Logic and spot any errors that would stop the Flow from being activated.


Test Flow

Knowing how to test a Flow is a key check for developing a Dynamics Solution and a skill for the MB-200 Power Platform Core Certification.

We can activate monitoring on our Flow by opting to Test and then specifying whether we will automate the trigger to the Flow, or we will trigger the Flow our self in Dynamics 365.


With this done, we can then test in CRM.

In this example we update our Release Record and ensure the Release Stage is updated.

The Testing in Flow then allows us to see the logic happen in real time and track the execution of our steps – so in this example:


Here we can see the Flow hitting the 1st Condition and then forking to the ‘if no’ path of the logic – this is where we can see a common problem when building Flows for Dynamics 365, I have supplied the Text Value of the Option Set, but Flow needs the Number Value behind this Option Set Value.


From this Testing Fail, we can adjust the logic and repeat our Test.

Now – when we come to Re-Test our Flow, we have a brilliant option for accelerating our testing.


You’ll come to love this feature

This option re-runs our logic for the same trigger that we use tripped manually in Dynamics 365 – meaning that we can avoid going back into CRM to re-update our Release record, we can instead just stimulate the event again from Power Automate itself.

This Build, Test, Edit, Re-Test cycle will form our main ‘gameplay loop’ for building a new Flow, particularly as we learn how to use each type of step available.

When Testing, we will have three main outcomes:

  • The Flow works!  But the logic doesn’t do quite what we want it to do – either the logic forks to the wrong end point because our conditions were not right (as we saw above with the Option Set) or the outcome is not what we expected.  However outwardly the Flow will look like its working, which means it passes Technical Testing but not Functional Testing.  This particularly is where good testing from ourselves as the Application Consultant is required.
  • Exception!  The Flow breaks within our logic and reports an error at one of our Steps.  This is where we need to re-edit the Flow, fix the error and then re-test to see if then passes Technical Testing.
  • Success!  The Flow finishes and does what we expect.  This then passes our Unit Test – but this is only testing this one unit of logic, we still need to test the wider solution and, most importantly for CRM, test the User Story to check that the overall experience works for the end user prior to UAT.

This then gives us our Flow-way of implementing business logic in Dynamics that traditional Workflow was not capable of.

As a Integrate-Anything Platform, Power Automate is still less-code rather than no-code in some ways, and so you may find some friction when moving from Workflow to Flow given the differences.

But the platform is much more flexible – and the ability to design and build workflow that moves across a variety of systems to build a single solution is key.

This has been a goal for many organisations over the years, and a low-code or no-code platform here can be game changing.

More Reading on Power Automate

Introducing the Common Data Service (current environment) - https://www.briteglobal.com/blogs/community/whats-new-in-common-data-service-connector/

Microsoft Documentation on the Common Data Service (current environment) - https://docs.microsoft.com/en-us/connectors/commondataserviceforapps/

Creating a Flow for a Many-to-Many Relationship - http://www.crmcs.co.uk/content/creating-a-flow-to-add-a-many-to-many-relationship.aspx

This gives a quick worked example for implementing business logic in Flow that was previously not possible via traditional workflow – and so can be a good example of a low-code way to implement a requirement that previously required code.