Secret ingredients to quality software

SSW Foursquare

Rules to Better Power Platform - 4 Rules

  1. 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 Common 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
    Figure:Use Common Data Services (Current Environment) instead of Common Data Services

  2. 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. 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

  4. Out of the box, any user with the correct licence can create environments. If you are managing Power Platform and would like to restrict environment creation and management only to admin then change the global settings:

    1. Sign-in to the Microsoft Power Platform admin centre at
    2. Select the Gear icon (⚙️) in the upper-right corner of the Microsoft Power Platform site.
    3. Select Power Platform settings.
    4. Select Only specific admins.

    power platform settings
    Figure: Set environment creation to admins only

    Once the settings are changed only Global Admin, Dynamics 365 Admins, Power Platform Admins will control the environments.

We open source. Powered by GitHub