Building a New Scheduled Process using Flow

Flows in Power Automate give us the option to run regular scheduled workflow that is not dependent on a Trigger or Event – a Power Platform version of the traditional Windows Server Scheduled Task.

This is a decent improvement on how Dynamics 365 previously used Wait or TimeOut Conditions in Workflow to affect ‘wait-until-X-then-do-Y’ type logic.

Historically we would have a number of Cases or Opportunities waiting for a Date and then taking an action. (typically creating a Task or other Activity)

From a design point of view, this could give us a challenge, as each Waiting Workflow would be its own independent piece of logic and this could be difficult to keep pace with – particularly as the Waiting here could run into Weeks or Months depending on the Workflow.

(this could lead to a common problem in Dynamics where a system would have 100s or even 1000s of Waiting Workflows that were doomed never to wake up as the condition had passed, but were still slowing down system performance)

Whereas a scheduled daily or weekly routine that identifies what’s needed and takes action is much easier to maintain and govern.

This post will look at how we do this in Power Automate using a Scheduled Flow, and how this works with Dynamics 365.

Getting started, we can create a New Flow from scratch or from an existing Template.

When clicking NEW we will notice the following options.

We will notice several other options here that match closely to how we may have built traditional Workflows in Dynamics.
Automated – similar to Asynchronous Workflows of the type found in Dynamics since v3
Instant – similar to Synchronous Workflows in Dynamics since CRM 2013
Scheduled – designing a regular Process or Scheduled Task within our Office 365 Tenant
Business Process Flows – similar to BPFs within Dynamics

For this guide, we will create the Scheduled Flow.

The next step will be giving our Flow a Name and defining the schedule for how and when our logic will run.

Creating a new Scheduled Flow

Within CRMCS, we track a number of Deliverables as ongoing mini-Projects or larger Changes for a Client, and we set a Communication Plan to communicate our progress and next steps on each Deliverable each week.

We want to issue an Activity to provide the Update for each Active In-Progress Deliverable each week at 4pm on Thursday. (this allows the updates to be collected and then communicated out to our Client Stakeholders by midday on the Friday)

We can use this example as a guide to building our Flow:

When building Flows for Dynamics 365 or PowerApps, using the Actions for Common Data Service (current environment) will enable functionality over Actions for Common Data Service where we need to pick an Environment

We can then start our Flow by pulling back a segment of records from Dynamic and execute our Business Logic on each in turn.

The List Records Action in Flow can be powered by a Fetch Xml query, allowing us to build the query of records we want from Dynamics using the Advanced Find. (instead of using the Filter Query parameter and having to supply the oData Syntax)

Building a Query in the Dynamics Advanced Find that we can export as Fetch Xml to be used in our Flow List Records Action

Inserting the FetchXml into our List Records Action in Flow

We could place all of our conditional logic in the Fetch Xml or Query itself, but if we wanted to explicitly query a value with each record we list, we could also a Condition inside the List Records Loop.

Whilst adding a potentially unnecessary Step into the Loop, this can be better for clarity and debugging to have a Condition explicitly separated from the Query.

In this example, we could add a Condition to confirm that the Deliverable is due an Update, so Deliverables that already have a recent update are ignored from the loop and so duplicate pending activities are not created.

Note however that any values we want to use in our Condition must be in the Select Query of the List Records action, as otherwise our Flow will not have retrieved the data in the record for us to check against.

We can sandwich a Condition between our List Records and next Action Steps as way of controlling which records result in an Action – particularly for Testing our Flow

We can then define what action we want our Flow to take on a regular basis for each record returned by our FetchXml Query.

In this example, we can ask the Flow to create a new Activity Record for the Owner of the Deliverable to supply an Update on its progress.

We can implement this using a Common Data Service Create Record Step – and supplying Fields from the Select Query Parameter of our List Records to use as Values for the New Record we create.

With the following steps in place, our Flow will be ready for Testing:

When do we want the logic to happen – Reoccurrence
Retrieve the Data we want to act on – List Records
What action do we then want to take – Create Record

This obviously does not describe all Scheduled Flows we may need, but gives a good example of how the Reoccurrence and the Retrieval of the initial data to work with replaces the Trigger Event in Dynamics for our ‘average’ Flow.

We can then test our flow.

Despite the same text about ‘Trigger your flow manually’, the Test in Power Automate will test as if the reoccurrence is running now and so give us the right way of Unit Testing our logic.

Setting a Lookup Value in Flow when using the Common Data Service

Now, setting a Lookup Field in Flow is a bit of a gotcha, we need to include the following syntax:

entity-schemaname(<Guid>)

But the Entity Schema name is not exactly the usual DB Name for the Entity, but DB Name Plural.

So if we were setting a Loopup Field to point to an Account Record:

accounts(<Guid>)

This can be doubly confusing for a Custom Entity where this becomes:

new_myentitys(<Guid>)

So in example above, we set the Deliverable Update Activity to be linked via the Regarding field to the Deliverable via the following configuration in Flow:

Or when setting the Owner Field:

For getting this right, I found the following two articles helpful:

Tip for setting a Lookup Field using Flow for a Create or Update Action in CDS

https://crmtipoftheday.com/1311/use-entity-name-in-flow-lookups/
Notes on the Plural Name that Dynamics will assign for Custom Entities
https://linnzawwin.blogspot.com/2019/11/power-automate-how-to-set-lookup-field.html

As per the second article however – the plural name that Dynamics gives for a Custom Entity can be tricky. We can determine this EntitySetName by running the following HTTPS Request against our Dynamics Environment:

https://mycrm.crm11.dynamics.com/api/data/v9.1/EntityDefinitions(LogicalName=’new_myentity’)?$select=EntitySetName

In our browser of choice, this will give us a Response informing us of how Dynamics regards the EntitySetName of our Custom Entity:

"@odata.context":https://mycrm.crm11.dynamics.com/api/data/v9.1/$metadata#EntityDefinitions(EntitySetName)/$entity,

"EntitySetName":"crmcs_deliverables",

"MetadataId":"e9e7453c-5e22-ea11-a810-002248070f4c"

The Plural Name is a bit of an odd one for long standing Dynamics Vet’s as it comes from the newer REST API for working with data – but you get used to it after a few peculiarities.

With this format for Lookups, we can create new Records in our Scheduled Flow that have the right Relationships to other records.

Using Scheduled Flows

We’ve seen above how to setup a basic ‘Activity Spooler’ that will issue out Activities on a regular schedule – and this is a common Use Case.

For example, we use similar logic in the Property Management Industry to handle reoccurring jobs being allocated to 3rd Party Contractors.

From experience, this ability to have regular daily, weekly or monthly processes can be tremendously useful when it comes to system design – as it allows us to build rules into the system for highlighting exceptions or when a User should take action.

I’d always advise against having too many Activity Generators in CRM, as having too many Tasks or Prompts can be self defeating. (after about 5 Email Alerts a day, its starts getting easier for Users to zone out and the Alert to no longer be an Alert!)

But having hard and fast rules for when a Transactional Record (such as a Case or Opportunity) needs to be Highlighted or Escalated can be very useful – particularly if tied to Highlight Reporting, a good collaboration system in Teams, or just good use of Views or Dashboards in Dynamics.