RSMUS.comMicrosoft Flow is a new workflow engine that was released in 2017. Flow has many connectors to many different applications and file types. The bulk of the connectors are free, any connections tagged as ‘Premium’ are not free. To name a few, Flow can connect to SharePoint, Twitter, RSS, Outlook, SQL Server, Dynamics 365, Excel Online, Bing Maps and many more connectors (see https://us.flow.microsoft.com/en-us/connectors/ to see a full list of currently available connections).
This post is going to highlight the strengths and weaknesses when using Flow in conjunction with Dynamics 365 Customer Engagement (D365CE).
To clarify some frequently asked questions:
- Flow is not replacing the built in Process engine that we are all used to
- Flow is async, so no real time workflows. Depending on your plan you could be waiting up to 15 minutes for a flow to trigger (https://us.flow.microsoft.com/en-us/pricing/)
- Flow will work with custom entities and fields
- Flow can connect to more than one Dynamics organization, and can also trigger on and update a single organization
- Despite the FAQ from Microsoft this is not something I would put in the hands of a “line-of-business user”, the ability to create and manage flows should definitely be kept in the hands of an administrator (https://docs.microsoft.com/en-us/flow/frequently-asked-questions)
Strengths:
- You can loop through related records. One weakness that the built in Processes have is that we do not have any ability to loop through a list of records based on a relationship. With Flow’s ability to loop through related records means that some of the functionality that was reserved for custom plugins or an ETL tool is now within the realm of a free GUI tool.
- Simple Integrations and data loads. If you do not currently have an ETL tool, Flow is a great tool to keep your meta data lookup tables in sync between your production and development environment (*note you cannot force the GUID of a record created by Flow, so your lookups will still break when pushing from on environment to the other). If you are using the import wizard, Flow is also a great tool for staging data in Dev, getting business approval, then pushing that data into a production environment.
Weaknesses:
- Cannot have multiple triggers for one flow logic and cannot pass parameters between Flows. This means that if your flow needs to trigger on create and update of a record type, you need two individual flows.
- Add a filter to your Flow’s trigger. Even if the first step of your Flow is a check condition with no False Branch, the evaluation of that check condition counts toward your monthly execution number.
Use Cases
Iterate through and update child records:
In a typical D365CE implementation there will inevitably be at least one record type that will only ever exist as a child to another record (think Incident and Account/Contact). We will commonly populate the Primary Field of such records with a specific set of data points. That way these child records are consistently named and the end user does not have to enter a value. For Incident’s we will typically set the Primary Field to “[Customer] – [Case Type]” or something along those lines. The issue is that if our customer’s name changes all of our Incident’s will still have the old customer name in the Primary Field. There is no way to fix this using the built in workflow engine. You could add JavaScript to set the primary field value, but that means that the Primary Field will be wrong until someone opens the Incident form.
However, Flow can handle this requirement quite easily. On update of Account, list all Incidents for that Account, Apply to each, and an update to fix the Primary field of the Incident.
In the screen shot below I am setting the Primary Field to [Account Name] – [Subject] and as the Subject is a lookup field I need a Get Record step to get the text value of the subject field. This example also highlights one of the weaknesses of Flow. An Incident could be the child of an Account or Contact, so you would need a flow for Account updates and Contact updates.
Roll up indirectly related record values or through multiple relationships
The List records step is also the star of the show for this use case. When creating a list record step, you define a Web API filter query. This gives a significant amount of flexibility when it comes to what records are getting returned. The records do not need to have a direct relationship to the record that you are rolling up to.
In the screen shot below I have a Pet Owner entity and a Pets entity. I want to roll up a value from the Pets entity to the Pet Owner record. My filter statement returns all of the pets where the Pet Owner lookup = the Pet Owner record that triggered the flow.
The rest of the steps will increment a variable for each Pet record, then set the field that on the Pet Owner record to that variable. The field on the Pet can be a simple, calculated, or a rollup field. The field on the Pet Owner has to be a Simple type field.
These are only two outlined examples of the more exciting possibilities that the Microsoft Flow engine provides.
To learn more about how you can take advantage of this and other Dynamics 365 features, visit RSM’s Microsoft Dynamics 365 resource. To make sure you stay up to date with the Microsoft Dynamics Community, subscribe to our Microsoft Dynamics Community Newsletter.
For more information on Microsoft Dynamics 365, contact us.
By: Steve Trefz
