It would be good if you could get the old value and the new value. Then you could use it in an email or push notification. Such as status for customer XXX changed from Active to Inactive or something like that.
would be awesome. Have been trying to do this with a flow from dynamics and a microsoft flow. But ran into the problem that processessions can`t be tracked ๐ hope this feature will come soon.
And its already possible within dynamics with the workflows to start when a field is changed. So this must be possible in Microsoft Flow.
My blocker is a specific gap between the existing functionality in Dynamics 365 CRM Workflow and Plugins vs using the current version of the Dynamics/CDS connector for Flow.
In traditional Dynamics Workflow and Plugins, I can filter the firing of the event to only specific fields. (e.g. only fire if the customer status changes.) - Without this capability in the Flow connector for D365/CDS, the process fires multiple times whenever a record is touched - regardless of the need - and if the flow's objective is to update the record in dynamics, it results in an infinite loop.
The indiscriminate firing of the flow results in an excessively chatty process that restricts its usefulness. (e.g. if I'm paying for a 3rd party geocoding service that is only needed whenever an address is updated, I would be forced to pay for a huge amount of unnecessary usage since the service would be called repeatedly even when the address has not changed.)
This feature would be great. This is much needed, please. The majority of my workflows trigger on the update of a field. Once I realised Flow canโt do this, I have continued to use the Dynamics 365 workflows. Fingers crossed this feature appears soon.
The lack of this feature will keep us from moving to using Microsoft Flow. We can easily do this with Dynamics 365 workflows, so it's hard to understand why this functionality wasn't added.
This might be old news to you all now, but Iโve seen now in Power Automate that Flows can now be started or not started using something called a โConditional Triggerโ on the actual Trigger.
What this means is when I add a Trigger to the start of my Flow I can now add some logic to see if the Trigger should fire or not. An example would be if I had a Flow that sent me an email when an Opportunity was updated AND marked as Close Won.
Previously, before I discovered Conditional Triggers, the Flow would run every single time an Opportunity was updated. I would have then created a Condition to check if the Opportunity was Close Won. If it wasnโt, the Flow would cancel. But of course, the Flow ran to begin with, costing me one additional run and just seeing redundant.
This caused me a great deal of frustration as it was just pointless to have the Flow running for no reason.
Now, this no longer happens when I use a Conditional Trigger. I can put a condition on the actual Trigger to say when an Opportunity is updated check first to see if it is Close Won. If it is, run the Flow; If it isnโt, donโt even start the Flow.
This is a game changer, as they say. Flow now has the feature I need to stop building workflows in Dynamics and move to the Power Automate for all my asynchronous workflow requirements.
A couple of things to mention here, is, I believe:
- Conditional Triggers, only work with the Common Data Service (Current Environment) connector. - Also, the Common Data Service (Current Environment) connector can only be selected when you are creating a Flow within a Solution.
- The experience of creating a Flow compared to creating a workflow in Dynamics is vastly different. Flow has a real learning curve and doesnโt have the easy of use drop down and lookup fields like Dynamics does, so it takes much longer to build a Flow when you are just learning. But it is the future, so better to learn now than later.
Lastly, below are two great YouTube videos from Audrie Gordon and Jon Levesque from Microsoftโs Power Automateโs team about Conditional Triggers:
