Home / Business & Management / Business Technology / Dynamics 365: Working with Power Platform Automation / CDS Connectors
CDS Connectors
.
In this section we’re going to be talking about working with the CDS connectors. This is how you will be connecting and working with data from the common data service. There are actually a couple of connectors that you can choose from and I want to make it clear which one to use for which types of use. You’ll notice that in the list of connectors there is a common data service one as well as a Dynamics 365 one. Now you might think that if I was building a Dynamics 365 project, even though I’m using CDS data, I should use the Dynamics 365 one to do the work.
Generally you want to always use the common data service one because it defaults to your current environment that you’re doing operations with. So when you use the connector, as you’ll see in our labs and hands-ons that you’ll do, you set the default environment. That means that it’s going to connect to the CDS that’s associated with that environment. The reason that’s important is because it allows you deploy projects and solutions that contain flows from dev, to test, to production without making any changes to those flows to point from dev, to test, to production. It automatically knows to talk to production when it’s deployed to production. The Dynamics 365 one, on the other hand, you have to actually explicitly set an environment.
So it is recommended to use any time that you’re doing integration between two specific environments. So let’s say I had marketing and sales in two different environments and I wanted to explicitly have a connector connect to the marketing to move something to sales or from sales to service if they were all different environments. I would use the Dynamics 365 one because it allows me to explicitly set those environments on the actions. For the most part, you’re safe to assume that you should always use the common data service one unless you have an explicit reason to use the Dynamics 365 one. Let’s talk about some of the triggers that are available from the CDS connector.
You’ll notice that I have two lists on the left and the right of the screen. The ones on the right are there to support existing flows that have already been built and require admin access to use. So while you’ll find them in the list, generally unless you have an explicit use case, you should proceed to use the ones on the left that are marked with preview. And there’s a good chance, at the time that you’re viewing this, that the preview label has come off of them. They are OK to use in production applications as now as they are fully supported. Now let’s talk about the different ones.
You have when a record is deleted, when a record is updated, when a record is created, and when a record is selected. Now when a record is selected– we’ll be talking about in more detail later in the course. It is used when you want to trigger manually from a model driven application and have it run with the context of that record. Now when you use the deleted it will trigger any time a record is deleted. We’ll be talking about scope on these different triggers because scope will determine when it runs, if it runs for all records that happen in an environment, or only ones that are created for you or somewhere in the middle.
Let’s talk about the data that’s provided with the CDS triggers when they fire. When a record is created or when a record is updated you get all attributes on it. Now when a record is selected is used you’ll only actually get the primary attribute, which is the name and the ID for that record and any fields referenced by the flow. This can be a little misleading because I know when I first started I did a when a record is selected, ran it, looked at it, and said, oh, the only data that is available is the ID. So I went ahead and proceeded to do a get record to get all the other fields that I wanted.
You don’t actually have to do that. As you reference the different fields it will automatically add those to the query that is run for when a record is selected. Now keep in mind with all of these if a field has no value it will still be present but it will have a null value. And we’ll talk about what happens if you provide a null value to an update or other action, you want to keep that in mind. But we’ll cover that in a later topic as you dive in a little bit deeper. Now in addition to the triggers the CDS connector also has several actions that are available.
You can create records, you can get records, list records, update records, as well as delete records. So create and update support similar scenarios as classic workflow. So if you’re trying to say, hey, could I build this in flow instead of CDS classic workflow, both create and update are there allowing you full support. Now the get record and the list record are something that open up additional scenarios that you can’t do with CDS workflow. CDS classic workflow doesn’t provide the ability to get a record or list record. So for example, if you wanted to get all the contacts associated with an account you could use list record to query those, pull those back, and process all the contacts.
Maybe you want to send an email to all the contacts that are associated with a particular customer that you’re working with. Delete also is now available. This is a frequent one that’s been asked for for CDS classic workflow that is not available. Supporting scenarios of cleaning up, or compensating, or just deleting records that are no longer needed as part of a scenario. Now as we get a little further in the module we’ll cover a lot more details on how to use the different actions and the triggers.
In this section, we’re going to be talking about working with the Common Data Service (CDS) connectors.
When you use the connector, as you’ll see in the labs and hands-on activities, you set the default environment. That means that it’s going to connect to the CDS that is associated with that environment.
The reason that’s important is that it allows you to deploy projects and solutions that contain flows from dev to test to production without making any changes to those flows to point from dev to test to production. It automatically knows to talk to production when it’s deployed to production.
For the Dynamics 365 one, on the other hand, you have to actually explicitly set an environment. So, it is recommended that you use this anytime you’re doing integration between two specific environments.
Join the discussion
Why do you think that the CDS connector needs triggers in order to work effectively?Use the discussion section below and let us know your thoughts. Try to respond to at least one other post and once you’re happy with your contribution, click the Mark as complete button to check the step off, then you can move to the next step.
This article is from the online course:
Dynamics 365: Working with Power Platform Automation
Created by
This article is from the free online
Dynamics 365: Working with Power Platform Automation
Reach your personal and professional goals
Unlock access to hundreds of expert online courses and degrees from top universities and educators to gain accredited qualifications and professional CV-building certificates.
Join over 18 million learners to launch, switch or build upon your career, all at your own pace, across a wide range of topic areas.
