Rules to Better Power Platform
When creating workflows in Dynamics developers take for granted when a solution file is moved across environments, things just work. To achieve the same with Flows we need to make sure that when connecting to Dynamics using the Comm Data Service connector, we in fact connect with Common Data Service (Current Environment) connector. This connector is environmentally aware and will immediately work when the parent solution is deployed to another environment, it doesn't require any post-deployment steps.
Tip: When searching for Common Data Services (Current Environment) it’s very easy to pick the wrong one:
Dynamics has come a long way since the early days and now sits under Power Platform. So why not take advantage of all the capabilities to make Dynamics sing. Prior to Power Automate and Azure Functions, a Dynamics developer would use a combination of Workflows (synchronous and asynchronous) and Plugins to extend the system.
While there is are still some limited scenarios for using Workflows (Power Automate doesn't yet support synchronous execution) and Plugins (again synchronous support), Microsoft is shepherding developers toward Microsoft Flow (Power Automate) for automation tasks, and this is a great thing.
Case for Power Automate instead of regular Dynamics workflows:
- A massive number of connectors from Act! to Zendesk and everything in between
- Can't find the connector you need? No problem, create a Custom Connector or just use a generic HTTP request
- Intuitive debugging experience, see errors immediately, fix and re-run failed flow
- Visually much nicer UI compared to Dynamics Workflow experience
The case against Power Automate instead of regular Dynamics workflows:
- No real-time workflow support, so if real-time workflows are needed then Dynamics workflows are the only solution for now
Previously when there was a more complex operation that needed to happen, for example, a complex scoring requirement for customer sentiment this logic would be contained in a plugin. Most Dynamics developers avoid writing plugins as they're a huge time sink, difficult to debug, and just not cool. The cool kids write the complex logic in Azure Functions.
The case for Azure Functions instead for Dynamics plugins:
- The developer requires zero Dynamics experience to implement an Azure Function (useful to have Dynamics experience but it's not an impediment)
- An Azure Function is a WebAPI endpoint and can be called by other applications
- Very smooth debugging experience
- Application Insights built-in
- The Dynamics layer can be abstracted away, Azure Function can implement the logic only
- Power Automate can sit in the middle of Dynamics and the Azure Function as the glue layer
The case against Azure Function instead of regular Dynamics Plugins:
- Plugins can register against many Pre and Post events whereas an Azure Function is a WebAPI endpoint
- Azure Functions are a paid Azure service, while extremely cost-effective, it is still an additional cost
When creating a Flow that connects to CRM, Flow gives you the choice of:
- Dynamics 365
- Common Data Service
- Common Data Service (Current Environment)
While it may seem like the obvious choice to pick Dynamics 365, but this would be a bad choice. The Dynamics 365 is deprecated as of April 2019. Use the Common Data Service (Current Environment) connector, it supports more data types and broader trigger scenarios.
Common Data Services (Current Environment) is only available if the Flow being developed is inside a solution. The advantage of using "Current Environment" is when the Flow is deployed across environments (Dev, Test, Prod) the connection is sticky to the environment to which it is being deployed. If a Flow is being developed outside of a solution, then use Common Data Services.