Running Microsoft Flow from within Dynamics 365 CE

Wouldn't it be great if you could trigger a Microsoft Flow from within Microsoft Dynamics 365 CE? Well, we have been able to do that since V9.0 release. Unfortunately, there hasn't been enough information published about how to set this up and do it. If you go to the online docs and search for embed Flow in Dynamics 365 you will either get a page that shows you how to enable the Flow button for Dynamics 365 or another doc how to get a Flow to appear in the flyout menu within Dynamics 365. So today I am going walk you through how to do it.

But unfortunately, they are skimpy at best and in the case of the second document listed, a little incomplete at best or a little incorrect as of the writing of this blog. Here is the main piece of information you need to know. Only Flows that start with the COMMON DATA SERVICE TRIGGER WHEN A RECORD IS SELECTED will appear in the Flyout. Button Flows, Recurrence Flows or Flows that start with any other trigger type will not appear in the Flyout. Additionally, as you would suspect the Flow has to be enabled before it will appear. Note: in a future blog post I will explain how you can get around this limitation of only displaying Flows using 'when a record is selected' trigger. Now to the fun part. I will show you a Flow that a user can run from within Dynamics 365. The business scenario is that you want to be able to send a broadcast Text Messages (SMS) to Contacts on a Marketing List. We will use the 3rd party service Twilio and other existing standard connectors to execute this process. Here is what the Flow looks like (if it looks a little scrunched on your screen, click on it to get a bigger view):

Let's break down each step of the Flow:

1. When a record is selected - this is the first event in the Flow and this Trigger allows the Flow to appear in the Flyout. It is connected to the Common Data Service (CDS) behind the environment it is running in. It will also prompt the user to enter in the message they want to send to the SMS recipients.
   
   

This is how the triggering event will present itself to the user. Pretty cool, Huh? Kind of like the old CRM Dialogs but not very pretty though, 😞

2. Get Marketing List - In this action we get info about the Marketing List we selected that we will use in later actions.

3. Using a Condition Check we make sure that we have selected a Marketing List that is of a Contact Type. If not it will send a failure notification to the user. Just a little sanity check that we didn't pick a list that is composed of Accounts or Leads. Also, note that this Flow is assuming we are working with a Static list, modifying for it to use a Dynamic list will be blogged about in a future post. FYI, Contact is a record type '2'.

Since the dynamic content is a little cut off, here is the full name.

4. Let's get the negativity out of the way. If the condition evaluates to False because the List is an Account or Lead list the User will get an email notification.

5. Moving back to the positive we can proceed down the happy path to get the members of the List.

6. Now the last step in data retrieval is to get the Contacts records themselves so that we can use attribute data from their records to send out the bulk SMS message. The way this is setup is we are only looping through the members of the selected Marketing list to get their info, not all the Contacts in the system.

7. Finally, we are ready to send out the SMS message. Well almost. We need to make sure the Flow doesn't try to send a SMS to a Contact that doesn't have a mobile phone number. If it does the Flow will fail for that Contact. Although it will still send out messages to all the other Contacts that have a mobile phone. So therefore, the Flow will show as failed in the Run History. Here is how we keep it clean and also alert the User if any Contacts fail the test. There is not a Condition check that we can use like Does Contain Data as we can in traditional Dynamics 365 workflow. So, we write a condition check that says return the opposite of empty, which if not empty (has a mobile phone) would evaluate as true. It is @not(empty(body('Get_matching_Contact')?['mobilephone'

8. Let's take a look at what happens if it evaluates False and goes down the If no path. What the Flow will do is to create an Outlook Task for the User notifying them that a SMS could not be sent for that Contact. Would it be less intrusive to send a list of all the failures in one record? Sure, but let's assume that this is an edge case and not the norm for the Marketing List.

9. Back to the happy path and the last Action. We are ready to send the message to the Contacts.

That wraps it up.