10 Best Practices for Developing Power Platform Solutions

Why does Microsoft hide the best practices in the Power Platform? In this post I will go through some best practices that aren’t always obvious to find.

Why are the best practices hidden?

The challenge within the Power Platform is that anybody has to be able to get started with software development.

Compare this with building a house. I can find all the tools and materials from my local DIY shop.

But would I end up building a house that I can live in?

To make it easy Microsoft has given us a DIY shop to get started with, finding the best practices is not always as easy as we would like it to be.

Best Practice 1 – Create an app

What can be more basic then you go to Power Apps Studio and you get started.

As a new developer I can see three obvious places top get started.

• Try new experience (preview)
• Let’s make a plan
• Apps

Try new experience(preview) is not really an option as I want to develop something that needs to go into production. So preview is going to scare me away.

Let’s make a plan, sounds good. I entered my wishes and like a genie in a bottle something got created. And when I hit the save button at the top, I’m even asked to create a solution. Hey that is great! Click on Save!

I’ve got a plan but nothing more than that. Ok, that’s not going to be it then. Also the Publisher on this solution has been set to CDS Default publisher.

Let’s go to Apps in the left navigation and click on New app. Ok we have 4 options available to us. I want to start with an empty app and after a while I might find the right option under Start with a page design.

We’ve now created an app but, … the app doesn’t live within a solution. This will mean that there is no custom publisher connected to my apps, tables, flows etc and internal names may be a bit ugly.

The right option to create new apps of course is to start with Solutions and then create a new solution before adding your app to the solution.

Best Practice 2 – Create a flow

So, we got started with Power Automate and managed to go to the Power Automate site. Where do we go? Well My flows sounds promising.

Quite quickly we will find the New flow

And we can create a new flow.

Like with the app that we created we now have created a flow that sits outside a solution. Before you know it you will end up with 100s of users creating 1000s of flows and you end up with a mess. Would you be happy for everybody to create 1000s of files in a single folder and hope for the best?

Best Practice 3 – Default environment

So you created yourself a new tenant and figured out how to get to Power Automate or Power Apps and you are ready to create your first Power Platform solutions. You go ahead and your apps are successful, and then you find out about environments. Many organisation create their solutions in the default environment.

So why is it so bad to use the default environment. I’m going to refer to the official Microsoft documentation before listing some insights:

• Every user has access to the default environment
• Some connectors can’t be blocked
• Users that leave the organisation leave their flows and apps behind.
• SharePoint custom forms (Canvas Apps) and flows appear in the default environment
• The default environment is often used to experiment with so do you trust that Dataverse environment to be clean?

Best Practice 4 – Multiple Environments to support ALM

Following the use of the default environment comes the implementation of Application Lifecycle Management (ALM).

Would you be happy for developers to update production systems and break these systems? Can you afford downtime?

In general organisations should create at least the following environments:

• Development
• Test
• Production

Although, I would recommend to include environments for

• UAT (User Acceptance Testing)
• Like-Production

To implement the general ALM process you will need to give your developers an environment to do their work with. Then then they think they have completed their work deploy the solution to Test. Ideally, if that deployment is successful and testing has completed you want to deploy to UAT before the deployment to production can take place.

The UAT environment becomes especially important if your developers need to test the next piece of work, while the developers need to test their next set of changes. Quite often UAT Users get in the way of development when UAT and Test become one.

I also hear many people say that they do their testing in Development. How do you test the deployment process in Development?

Best Practice 5 – Variables in flows

Now, I’m getting to the reason for this post. Yesterday, I commented on Damien Bird’s post on LinkedIn about Variables vs Compose actions.

When you start with flows, it is so easy to find the variable actions.

But why should you not use variables?

There are a few reasons.

1. Initialize variable steps are cluttering the flows. How often have you seen 20+ actions like this at the top of the flow?
2. When you use variables in loops, and you enabled parallelism/concurrency, then your parallelism will not work as the order of the variable operations is important.

Many times I see the Append to array variable action used where really, Pieter’s method should be used instead.

And if you have multiple variables that don’t really change through out your flow then a single Compose action will help as well.

Have you noticed that when you select an Compose action in your Dynamic content, the name of the Compose step isn’t shown. Even though you have named your Compose action?

Setting your Compose action to something like this will resolve that:

{
  property1: "value",
  property2: "value"
}

outputs(‘Compose’).property1 will now display a lot better. Alternatively, you could also use a Parse JSON action of course.

Best Practice 6 – Retry policies on flow actions

When you add actions to a flow, they may retry when an action fails.

In the following example I created a flow with a child flow, and the child flow may retry. By default action have a retry setting of Default in the retry policy. Why would you want a Child flow to ever retry. Maybe an action inside the child flow but rerunning a child flow hardly ever makes sense.

Also, if anyone has a good explanation why the Retry Policy is set within a section called Networking …

Best Practice 7 – Power Apps – Responsive or Fixed

I’m not going to argue if apps should be responsive or fixed, but I would definitely say that responsive apps are better. Responsive apps may be slightly harder to develop (in the beginning), but if the end result is better with responsive apps then why is the default when you create a new app set to fixed?

If you are ready to develop responsive apps, then I would look at setting this option to Responsive all the time.

Hey, why are you stopping at 7 hidden best practices? The post is called 10 best practices! The next 3 best practices should appear in the comments. If you have any more best practices where you initially took the easy root, while the tougher route was just there, then please add a comment on this post.