Secret ingredients to quality software

  • Services
    • Products
      • Training
        • User Group
          • Rules
            • About Us
              • SSW TV
              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.

              If you still need help, visit our Power Platform consulting page and book in a consultant.

              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
                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 service accounts?

                Using a service account is a common best practice. If a flow is not shared with a group, it will be lost when an owner leaves the company.

                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

                power platform services accounts
                Figure: Good example – see arrows the names are service accounts that will still work after an employee leaves the company

                Do you have issues with connections in Power Automate flows?

                If a Flow is exclusively shared with a single user, it will be deleted shortly after that user is deleted. We aim to avoid having any deleted flows.

                For the above to not happen, share your flow with a group, so it is never deleted when the owner leaves the company or gets deleted.

                For e.g. Share with the SysAdmin group. Even when a connection string is lost or invalid, SysAdmins will get a notification to fix the problem

              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.


                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