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.
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...
Figure: Use 'Common Data Services (Current Environment)' instead of 'Common Data Services' 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
Figure: Dynamics Workflow Editor 
Figure: Flow Editor 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 Example: Using the deprecated Dynamics 365 connector 
Good Example: Using the Common Data Service connector 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:
- Sign-in to the Microsoft Power Platform admin centre at https://admin.powerplatform.microsoft.com
- Select the Gear icon (⚙️) in the upper-right corner of the Microsoft Power Platform site
- Select Power Platform settings
- Select Only specific admins
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.
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.
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.cominstead ofBobNorthwind@northwind.com) for connectors. This ensures continuity and security, as service accounts are not subject to frequent changes like employee accounts.
Figure: Good example – Groups and Service Accounts cleverly used to not lose any 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.
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.
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 Automate Azure Logic Apps Azure Functions Traditional API Pricing Per User Per Action or Hosted Consumption (CPU/Memory) or Hosted Customisable Target Users End Users IT Pros Developers and IT Pros Developers 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
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.
