SSW Foursquare

Rules to Better Power Platform - 8 Rules

The Microsoft Power Platform is more than the sum of its parts. Connect them together—and to Microsoft 365, Dynamics 365, Azure, and hundreds of other apps—and build end-to-end business solutions.

Want to be more effective and efficient in your business? Check SSW's Power Platform consulting page.

  1. Do you create a Solution and use "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 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. 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

  4. Do you control who can create and manage Power Platform environments using the admin centre?

    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 https://admin.powerplatform.microsoft.com
    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.

  5. Power Automate Flows - Do you use groups and service accounts?

    Using groups and service accounts is a common best practice in the Power Platform world.

    Groups

    In Power Automate, if a flow is owned by an individual and not shared with a group, there's a risk of losing it if the owner leaves the company. In such cases, no notifications are sent out, and even Microsoft support cannot retrieve the lost data or flow.

    Always share your flows with a relevant group. This ensures that the flow is not lost and that the group members receive notifications and can manage the flow.

    2023 07 17 17 16 51
    Figure: Bad example – The red arrow shows the user as an owner. It is not shared to a group

    Service Accounts

    Using personal employee accounts for connectors in Power Automate can lead to disruptions. For instance, if an employee leaves or changes their password, the connector linked to their account breaks.

    Utilize service accounts (e.g., info@northwind.com instead of BobNorthwind@northwind.com) for connectors. This ensures continuity and security, as service accounts are not subject to frequent changes like employee accounts.

    powerautomateowner
    Figure: Good example – Groups and Service Accounts cleverly used to not lose any flows

  6. Do you know how to use correct timezone in your Power Automate flows?

    When working with Power Automate flows, there are instances where you need to use or compare the time in your flow, by default, it is set to UTC.

    However, there are situations where using your local timezone might be more appropriate, especially for tasks or events that are specific to a particular region. It's important to choose the appropriate timezone based on the context and requirements of your task or system.

    comparing timedate without converting
    Figure: Bad example - Comparing Datetime in default timezone: UTC with UTC

    • Complex Time Zone Calculations: Handling time zone conversions manually can become cumbersome, especially when dealing with events and meetings across multiple time zones
    • Daylight Saving Time Issues: While UTC doesn't observe daylight saving time, your local timezone might. This can lead to confusion and scheduling problems when your local time changes
    • User Experience: In user-facing applications, presenting times in UTC without local context can be confusing for end-users who expect times in their local time

    So to convert it to the correct timezone, you can use built-in expression in your flow:

    convertTimeZone({{ array/object }}?[{{ 'timedate variable' }}], 'UTC', 'AUS Eastern Standard Time')

    Figure: Good example - You are comparing it in local timezone (i.e AEST with AEST)

    For further details on converting timezones in Power Automate Flow, refer to the Microsoft Learn - Converting time zone. For default timezones, refer to the Microsoft Learn - Default time zones.

  7. Do you use the right tool to automate your processes?

    power automate logo
    Figure: The power of Power Automate

    In the old days, if employees wanted something automated they would have to call up the development team and go through a long bureaucratic process to get a traditional API built. These days, there are heaps of tools that make this easy, quick and simple.

    Power Automate

    Power Automate lets power users automate away repeatable manual processes. They can go from zero to hero in under a day!

    For example say you want to:

    • Monitor an inbox
    • Read emails with the subject “Invoice”
    • Get the attached PDF
    • Put the PDF in a SharePoint Document Library (there is a connector)
    • Put a record in Xero (there is an API - no connector)

    These are all easy in Power Automate, and a tonne of code in an Azure Function.

    Connectors

    Power Automate provides heaps of out-of-the-box integrations that mean you don't need to code in authentication, security and custom integrations with APIs. So long as your logic is just moving data from one place to another it can be done really fast.

    Some of the awesome connectors that exist include:

    • CRM systems e.g. Dynamics 365
    • Emails
    • Microsoft Dataverse
    • Microsoft Office 365
    • Microsoft SharePoint
    • Custom APIs
      and more...

    Custom Connectors

    If the connector you want doesn't exist you can create custom connectors to access your favourite APIs and you can even throw your own code into them.

    Beyond the Basics

    DevOps with Power Automate is simple. You can package it up in a Power Platform solution and then deploy it to dev, test and production at the click of the button. That way you can skip building DevOps pipelines!

    However, once the logic gets complex or you need to integrate with custom systems, it's time to look at another solution.

    Azure Logic Apps

    Azure Logic Apps are a really awesome way to integrate different systems and transfer data. Azure Logic Apps take integration to another level, by providing all the same connectors as Power Automate + tonnes more.

    You can also configure RBAC for Azure Logic Apps providing extra security control.

    However, once you start to get complex loops, lots of variables or mathematical manipulation that is where it starts to fall over and you might be better off looking at something like Azure Functions.

    Azure Functions

    Azure Functions help make complex automation quick, easy and pain free. While they still need a developer, it is much easier to get things spun up and you can hook them into all sorts of built-in triggers.

    For large, scalable solutions Azure Functions provide the best automation capability.

    The best of all worlds

    In reality, automation solutions often combine these tools to make the best possible architecture.

    Perhaps you have an Azure Logic App (or Power Automate Flow) that gets triggered by input in Dynamics 365, hits an Azure Function to do some calculations which returns the data to the Azure Logic App and then sends an email to the user. That way the Azure Logic Apps handles the integration aspects while Azure functions takes care of the complex logic. You end up with the best aspects of both!

    Always keep in mind that you don't need to limit yourself to one tool.

    Benefits Breakdown

    By now, your head might be spinning wondering what are the advantages and disadvantages of all the automation tools. Here's a quick overview to give you an idea:

    Power AutomateAzure Logic AppsAzure FunctionsTraditional API
    PricingPer UserPer Action or HostedConsumption (CPU/Memory) or HostedCustomisable
    Target UsersEnd UsersIT ProsDevelopers and IT ProsDevelopers
    Built-In packaging for easy deployment
    Quick To Spin-up
    Heaps of built-in Connectors
    No Coding Required
    Built-in Triggers
    Vendor Agnostic
    Fully Customisable DevOps
    Robust Source Control🟠*
    Smooth Debugging Experience
    Easy Mathematical Manipulation
    Easy Modularization and Refactoring
    Easy Logic Flows and Looping

    * Has source control, but it isn't as smooth as traditional code

  8. Do you version Power Platform solutions before deploying?

    If you're not versioning Power Platform Apps before each deployment, you could be setting yourself up for a world of confusion. A lack of versioning can lead to difficulties in tracking changes, resolving issues, and managing the development lifecycle.

    The solution is straightforward: Add a version to your Power Platform Apps before every deploy. This way, you can keep track of what functionality is contained in a particular solution release.

    The Version Format

    It's not enough to simply add a version number; the format of the version number is equally crucial. We recommend using the format Year.Month.Day.Iteration because it helps to accurately track the release, providing a chronological snapshot of the deployment history.

    For example, if you're deploying the second iteration of a solution on the 31st of May 2023, the version number would be 2023.05.31.02. This format immediately communicates when the version was deployed and how many iterations were released on the same day.

    The Description

    Adding a comment to the description with the version number, the author, and a short description provides additional context for each version. This practice aids in communication among team members and serves as a reference point for future troubleshooting or development work.

    An example of a good description would be: Version 2023.05.31.02 - John Doe - Added new form validation rules. This description provides clear information about the version number, who made the changes, and a brief summary of what those changes were.

    Practical Examples

    Let's consider two scenarios - one following these rules, and one not.

    Bob is a Power Platform developer. He makes changes to a Power App and deploys it without adding a version number or updating the description. A week later, a user reports an issue that emerged after Bob's changes. However, Bob can't remember exactly what changes he made, and without a version number or updated description, it's difficult for him and his team to trace back the changes and fix the issue.

    Figure: Bad example - Bob didn't use a version number and it came back to bite him

    Alice also works as a Power Platform developer. When she makes changes to a Power App, she adds a version number following the Year.Month.Day.Iteration format before deploying. She also updates the description with the version number, her name, and a summary of the changes. When a user reports an issue related to her changes, Alice and her team can easily trace back to the version that caused the problem. They can quickly understand what changes were made and by whom, enabling them to efficiently resolve the issue.

    Figure: Good example - Alice versioned her solution nicely and she was able to resolve reported issues quickly and easily

    In conclusion, consistently versioning your Power Platform solutions before deploying, using a clear and informative format, and updating the description with relevant details will significantly improve your change management, issue resolution, and overall development process. Remember that good practices today save troubleshooting time tomorrow.

We open source. Powered by GitHub