In this video we show you how Microsoft’s Power Platform automates and simplifies business processes, interacts more intelligently with data, builds conversational interfaces – all within SAP.
So, here you are starting to work with Microsoft Flow and all you want to do is create a simple process that connects to Dynamics 365 for Customer Engagement. You find yourself flooded with question upon question after reading through countless blogs. What type of trigger should I use? How many runs do my users have per month? Wait, there are two connectors that can connect to Dynamics 365?
It’s a confusing world out there! Although we don’t have quite enough time to address all the above topics, this post will focus on the two types of connectors you can use to connect with Dynamics 365: The Common Data Service Connector and the Dynamics 365 Connector.
To start, let’s quickly address connectors and how they are used in the Microsoft ecosystem. Broadly speaking, connectors are how Microsoft Flow, Microsoft PowerApps, and pretty much all the Microsoft cloud systems are able to connect to one another via what Microsoft calls the “Common Data Model,” or CDM for short. According to Microsoft, CDM is:
“… the shared data language used by business and analytical applications. It consists of a set of a standardized, extensible data schemas published by Microsoft and our partners that enables consistency of data and its meaning across applications and business processes.” (Microsoft. “Common Data Model | Microsoft Power Platform.” Common Data Model | Microsoft Power Platform, 2019, powerplatform.microsoft.com/en-us/common-data-model/.)
By standardizing the way databases store and retrieve data, Microsoft has paved the way for businesses to take advantage of this shared structure by using Microsoft Flow, Microsoft PowerApps, and Microsoft Logic Apps to create seamless integrations and workflows between systems. If you’re reading this and wondering what is possible by utilizing these powerful engines, the answer is almost anything. Although outside the scope of this post, it is even possible to connect to other web APIs outside of Microsoft’s ecosystem and pull data into Flow without writing a single line of code – just a bit of JSON and you are good to go!
You can read more about CDM here at Microsoft’s website.
Now that we have talked about the foundational concepts of CDM, let’s talk about the Common Data Service (CDS) connector that builders are likely to see in Microsoft Flow. Previously, we mentioned that CDM is all about data structure standardization. This is an important concept in relation to the CDS connector because it is built in a standardized way to allow Flow to reach into any CDS database, no matter what Microsoft service/software is being connected to. Take a look at the image below: there are a total of only five actions for the CDS connector, four of which can be used as triggers. These five actions are all that is currently needed to start working with any Microsoft service – e.g., Dynamics 365 for Customer Engagement – that is backed by a CDS database. Although five may seem low, it’s intended to create a simple, easy-to-use solution for businesses to connect data between their Microsoft systems.
When selecting a CDS Action, you will always have to select the Environment and Entity Name that Flow should connect to. One of the most useful reasons to use the CDS Connector is that it has the ability to target the (Current) Environment. This is important when importing Flows into new environments. For example, if you built a Flow in a development instance of Dynamics 365 and wanted to import it into a production instance, selecting the (Current) Environment will allow Flow to automatically change any actions pointed at the development instance to the production instance instead of forcing users to manually change every action during each Flow import.
The other Flow Connector used to connect to Dynamics 365 is by far the most obvious choice based solely on its name, the Dynamics 365 connector. This connector connects to several Dynamics services, not just Customer Engagement. As noted in the images below, there are quite a few more triggers and actions here in comparison to the CDS connector, but they really are quite similar overall. The Dynamics 365 connector has more Preview actions, which generally return expanded results such as option set text values instead of their integer values. These expanded features are nice to have and can mean the difference between adding a follow-up action or not.
It is truly up to you, as in most cases they will function the same way, but there are still reasons to choose one over the other. If you will be regularly pushing updates from one environment to another, the CDS connector works brilliantly due to its ability to automatically change to the current environment. If you want all the available expanded data points, you may want to look into the Preview actions found in the Dynamics 365 connector, as it provides extra detail the CDS connector may not match. In a more technical example, someone may want to create a Flow that can dynamically change environments or systems based on a specific data point. By using the CDS connector it is possible to select Enter Custom Value in the Environment field, thereby giving the ability to write a formula to determine which environment or system should be interacted with based on a previous action’s data. Although only anecdotal evidence exists, it has been suggested that the CDS connector is more stable than the Dynamics 365 connector and that it will eventually become the only connector for Dynamics, but at this point it is difficult to prove or disprove either of those theories.
Whichever you decide to go with, just remember that you can’t really go wrong either way. In our experience with Flow, the system itself is quite stable and extremely powerful. Our suggestion is to play around with the different connectors to get a feel for how they work and what they can do.
Thanks for connecting with us here at PowerObjects, and as always, Happy D365’ing!