Secret ingredients to quality software


Rules to Better Power Platform

3 Rules

  1. Do you create a Solution and use the "Current Environment" when creating Flow for Dynamics?

    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:

    common data services

    Related Rule

  2. Do you take advantage of Power Automate and Azure Functions in your Dynamics solutions?

    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.

    Power Automate

    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

    Azure Functions

    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

    dynamics workflow editor
    Figure: Dynamics Workflow Editor

    flow editor
    Figure: Flow Editor

  3. Do you use the Common Data Service connector instead of the Dynamics 365 connector when using flows?

    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.

    bad connector use
    Bad Example: Using the deprecated Dynamics 365 connector

    good connector use
    Good Example: Using the Common Data Service connector

We open source. This page is on GitHub