Skip to main content

Flow - Trigger on update - Difference in CDS connectors

Trigger on update

Today we gonna look on options, how to trigger a flow, when an opportunity is set to status "won", using the different CDS/Dynamics connectors.

Dynamics 365

The Dynamics365 connector has been announced as depricated in April 2019, so it should not be used anymore. Still if you have a look at templates in PowerAutomate, many templates for this connector are offered, like:


It starts of with defining either a "When a record is updated" or "When a record is created or updated" trigger:


In the trigger you define to which CRM organization your flow should be connected and on which entity it should be executed.

Then you define a check condition, e.g. in this case to check if the status equals 1 (=won). In case the condition evalutes to true, you create a new project, else the flow does nothing.



The big short comings on this approach (according my point of view) are:
  • deprecated connector
  • flow triggers on every update, not only if the status has been changed

Common Data Service

The Common Data Service offers the following triggers:


In this case we choose the trigger "When a record is updated" and again choose the organization and the entity on which the flow shall run. In addition this time we can choose the scope in which the flow shall be executed and even the attributes on which the flow shall be triggered.

Again we setup a condition to check the state code and an action to create a new project.


So this looks a lot better compared to the options provided by the Dynamics365 connector, since in this case we can limit our flow to only run, when the status of the opportunity is being changed.

Common Data Service (current environment)

The Common Data Service (current environment) connector is only offered, if you add your flow to a solution. It offers only one trigger:


But once you selected this trigger, it offers far more options to choose, on which message the flow should be started:


Since we chose the current environment connector, we do not have to specify the organization. Again we can choose the entity, the scope and the attributes on which the flow should be triggered. 

Compared to the "normal" Common Data Service connector, in this case we have to write down the field names manually in the filtering attributes field, instead of being able to choose them from the dynamic content.


The advantage of this connector is:
  • Solution aware flow
  • More flexibility in regards to triggering message

Labels:

Comments

Post a Comment

Popular posts from this blog

Power Automate Get absolute Sharepoint URL from document location

Document Locations If you enable Sharepoint document integration in your model driven apps, you can define for which entities the possibility to upload documents to sharepoint shall be offered and you can define a folder structure. Possible folder structures can either be based on account or contact, which means if you create child items (e.g. opportunities, activities, ...) sub folders are created below. If an entity is enabled for document management a "Files" tab is added to the form of your model driven app and as soon as you click on that tab a folder is automatically generated on Sharepoint. Once the folder has been created you have options to create new or upload existing file or to open the document location (folder) on Sharepoint: What happens behind the scenes is, as soon as you click on the files tab your model driven app checks, weither a "document location" for this item already exists, or not. The document location is an own entity in C
1 comment
Read more

Send e-mails with a link to the record via Power Automate

Today we gonna have a look at how to send an e-mail with a link to a CDS record via Power Automate. In the good old classic workflows, you could directly reference the "record URL" from the dynamic data. But since UCI has been launched and you have the possiblity to target different apps, you already had to do a few more steps in the classic workflows as well. The URL to a CDS record consists of multiple things: CRM URL appid entity name record id So we will work this out one after the other. First we add a "List record" action to lookup the appid of the app, we target. We look for "model driven apps" and filter by the name of the app: Then we initialize a variable with the resulting app id: Then we initialize another variable and extract the CRM_URL: Then we fetch our records, where we want to send out a notification with a link, in this case we look for workorders fullfilling certain criteria: Now we compose the record URL: As a next step we create a new
2 comments
Read more

Working with Optionset lables in Power Automate

Connector Types Power Automate currently offers 3 different connectors, to connect Power Automate with your Dynamics 365 instance: Dynamics 365 Common Data Service Common Data Service (current environment) Today we will look on ways how to retrieve option set labels via the different connectors, for our sample accounts: Dynamics 365 This connector should not be used any more , since in April 2019 it has been announced as being deprecated. https://flow.microsoft.com/en-us/blog/nine-new-connectors-in-april-and-improved-visibility-into-trigger-failures/ With the Dynamics 365 connector it was quite easy to work with optionsets, since it offered both the optionset value (int) and the optionset label (name) in the dynamic content: And here we go, these are our results: Common Data Service Since the Dynamics 365 connector has been deprecated, this is the connector you should use. If you perform a "Get record" or "List records&
13 comments
Read more