Microsoft Flow Vs Dynamics 365 Workflows - Part 1
I’ve seen some chatter recently about people's use of Microsoft Flow over Dynamics 365 Workflows. Some people are choosing to solely write flows, others are choosing a mixture of the two and others not embracing this new technology.
The newer Microsoft Flow has a lot of advantages, it can connect to multiple sources like SharePoint, Twitter, Dynamics 365, Twillio, Exchange and can get data or update data in these sources, action dependent. This makes it an extremely powerful tool. Flow is also extendable, meaning that you can create your own connectors and actions. There are some built in tools which can help with Flows as well, like a scheduling engine and an approval engine.
Workflows are still a fantastic tool as well, Workflows can create records, send emails, create tasks, update records. They can do these things from multiple triggers like when fields are updated, statuses are changed, records are created or deleted. It doesn’t have a built in scheduling engine or an approval engine but both can be created in a way, using workflows.
I wanted to write a multi part blog about using both; some advantages and disadvantages with building a similar solution using both. One of the pieces of functionality I get asked for a lot is an approval engine, specifically so sales people don’t give the house away. I will be building an approval engine to request approval when a quotes discount goes beyond a certain level.
Lets begin with Microsoft Flow. A bit of technical data here, with Microsoft Flow you have a set number of runs of Flows a month, meaning that when these run out, the functionality stops unless you purchase more Flows. This is important due to the first step.
I’m going to skip over creation of fields in Dynamics and instead just focus on the fields and functions of Flow.
The first step in this is to set a trigger, how are we going to trigger the flow to run. Flow has a number of triggers you can use but in our example, we are going use “When a record is Updated” in Dynamics 365 CE. We will choose the instance and the entity we want this to run for.
This trigger works fine, however there are no filters and we can’t choose which fields are updated. This leads us to our first gotcha, this flow will run every time a quote is created or updated, meaning if you update or create quotes over the limit of what you get as part of the basic Flow plan, it will stop working.
There is a solution to this which is that you can use the CDS 2.0 connector instead of connecting to Dynamics 365 directly. This is a premium connector so you require Flow Plan 1 or 2 to be able to use it, which could be an additional cost.
Next I’ve added a step to get the user details so these can be used later on, but this is not strictly necessary. I’ll show where I use this later on. I get the details of the user that owns the record with the below data/picture.
Then I put a condition into the Flow to check if the Flow should be run or not, in my example below, I just use a simple yes/no field called "Approval required" but you can do this on discount percentage being too high or any other field.
An interesting point about using a two option optionset in Dynamics and Flow. Any other option set you would check it either via it’s value or it’s label. If you use a two option option set, the returned values are true or false. Took me a few tries to understand why it wasn’t working.
Going down the yes route of the condition you can then begin the approval action. Create the approval action, choose basic and fill in the details. The below is a very basic approval with data that i’ve passed in, you can make it more complicated if you wish. I’ve included some details about the Quote ID in the title and details of the approval, the requester is where i’ve used the get user details to get the email address of the owner of the record. In the Item Link I got the URL from any Dynamics record and inserted the GUID (which is the Quote field) into the link between the %7b and %7d; this gives you an accurate link to click on. Handy!
Next we go into another conditional check, whether the approval was approved or rejected. Here we set the response to equal Approve and going through the Yes condition, leads us to our next step.
We then update the original quote record to say the approval is no longer required and populate the approver and date it was approved.
So what does all look like in practice? We trigger the record which starts the flow. The flow sends the approval which is an email. It looks like this.
The email lands into the inbox of the approver with helpful approve/reject buttons, meaning the approver doesn’t even need to open Dynamics 365 to view the quote before accepting or rejecting. There is even a reason box which can be populated and then fed back into D365. This is especially useful for when people are out of the office.
We can then see the flow updating dynamics with these details.
This is a pretty straightforward method of creating an approval engine...considering it’s already created for you, but you can add logic around it and hook it into Dynamics to make something useful. This can be used in multiple ways in Dynamics, quotes/opportunities, custom entities like holiday request, overriding of chargeable items on service calls etc.
The fact this approval engine exists is a great feature of Flow and the ability to reply from within emails make this useful for most organisations.
Ciao for now!