Guide and Empower Makers to Follow Best Practices

Published by Valentin Mazhar on , last updated on

Share

“I wish our Makers would clean up what they do not use!”…. Have you ever heard that from an Admin? I have… I have also seen the suffering caused by having too many Flows and Apps in a tenant. It can, in many ways, make our life as Admins more difficult. In this post we will discuss how we can further guide and empower makers to follow best practices with a Power BI template.

Which Power Platform best practices are we talking about and why shall we even care?

The purpose of this article is not to list all the best practices recommended for the Power Platform. There are many valuable suggestions out there, such as the 2023 Power Apps Coding Standards For Canvas Apps proposed by Matthew Devaney which are hugely valuable. From a Maker’s perspective, all these standards and recommendations form a gold mine. Following them will in turn help to improve performance, scalability, maintainability, user experience, and much more.

From a governance perspective, not all best practices are equivalent. What is even trickier is that most of the time the important ones for Admins are not the first priorities for Makers, which is understandable… and difficult at the same time. Let’s look at a few of my personal favourites.

If you don’t need it, remove it

If a Flow or an App is not used and not needed, best is to just to delete it. I am not saying that occasionally keeping backups just in case is a bad thing. We all have some Flows or Apps we feel proud of and that we want to keep at hand in case we have to re-do something similar in the future. But keeping countless Flows and Apps just because we moved on to other things and forgot about them is pretty much like forgetting to take the bins out. If you keep them long enough, it smells.

Let’s look at this from the admin and governance side, a no-brainer. The more objects there are on the tenant, the more resources are needed to collect data about them. It also generate a lot of noise, which prevents us from identifying what we should really look at. It also occupies storage in Dataverse, which has to be paid by someone, somehow…

From the Maker’s point of view now, one could argue that it does not matter that much, they can just leave all the unused Flows and Apps at the bottom of the list or in these environments that they no longer use. However, comes the day that an issue occurs on a specific flow, and the support team is struggling to access data about it because their central inventory is not up to date, this will be a different story. It is also usually appreciated by Makers when a successful solution is identified by the CoE who can then facilitate a demo to inspire others and replicate the solution elsewhere. This is easier when there isn’t too much noise.

Describe, describe, describe…

Adding a description for each Flow and App can go a long way.

  • As a Maker, it makes it easier to remember what the Flow/App does without having to open it. This becomes even more useful during hand overs
  • As an Admin, seeing the description of Flows and Apps centrally helps to gain some quick insight about what the platform is used for. This can be used to identify potential risks, success, re-usability opportunities, duplication…

Avoid sharing Canvas Apps with the entire tenant

This option can actually be blocked by tenant admins. Though there are situations when it can be useful. Makers tend to overuse this functionality. As a best practice, it is always best to only share an App with the users who need to use it. Sharing an App and the underlying data with more than the ones actually needing to use the App cause problems regarding compliance with internal and external regulations. It can also create confusion for users browsing through Power Apps and seeing all these Apps they don’t know.

When a Maker shares a canvas with “Everyone in …”, it is not clear exactly what type of users are included. My assumption is that it includes all the “Members” of the Entra ID (ex “Azure Active Directory”). If that’s the case, the problem is that there might be some users that are technically “Members” but not considered as part of the organization. A best practice would be to leverage dynamic security groups instead. This way we are sure of who is included in such groups.

Use Solutions

Solutions can be used to package Flows, Apps and other objects together. Think of it as a “folder” for Power Platform objects. They present several benefits such as:

More info about Solutions can be found here. There is an environment setting (still in preview) to enforce the usage of Solutions for cloud flows and canvas apps. Any (most) Flows or Apps created are then automatically added in the default solution by default. This can be relevant for some environments, for others it might not be.

How can we guide and empower Makers to follow these Best Practices?

“Empower”… This is the key and certainly not “direct”, or even “force”. We can do many things to guide and empower makers to follow these best practices, including:

  • Communication: this is the first point. Make sure your Makers know and understand the rationale behind these recommendations. Be curious as well to understand what is preventing them to follow them. This takes efforts and usually requires various channels. You don’t want to overload them with a huge amount of things neither. I am only proposing 4 points here. You can introduce more later.
  • Data: this is the main point of this article. Although Microsoft is making progress there, Makers can still have a hard time in getting an overview of all their Flows and Apps across environments and identifying what they should take action on. This is where you can help. You can provide them with a dashboard that will show them all of this in a user friendly way.

Leverage the CoE Starter Kit to provide a Dashboard to Makers for Best Practices

We present and discuss the CoE Starter Kit in a separate article. This freely downloadable kit allows admins to collect data about the platform usage as well as leverage processes and solutions to govern the platform.

The kit already proposes some Inactivity management system, automatically deleting what could be removed after asking users to confirm they are ok with it. But nothing will ever replace the value of sharing the data to Makers directly. Informed Makers lead to happy Admins and healthy tenants.

It is possible to leverage the data collected in the CoE Starter Kit and provide a dashboard to share to end users to let help them identify the gaps in their best practices.

Screenshot of dashboard to enable Makers to follow best practices
Screenshot of dashboard to enable Makers to follow best practices with Flows
Screenshot of dashboard to enable Makers to follow best practices with Apps

For example, this Power BI report contains 3 pages:

  • Overview: key metrics around amount of Apps and Flows owned, amount of Apps shared with Everyone, etc….
  • Flows: detailed list of all owned flows across environments with link and additional information about each
  • Apps: same as for flows

On each page, it is possible to add “?” icons with tooltips and redirecting to a guidelines page for Makers to understand what is expected of them.

A Row Level Security role has also been created so that once published online, Makers connecting to the report will only see their own data.

Is there any Power BI report templates for this?

There wasn’t… But now there is! I created a Power BI template with a few parameters for you to leverage this report easily. Check out my GitHub repository to download the template “My Flows & Apps Template.pbit”. I hope this will help you encourage Makers a better hygiene for their Apps and Flows!


Share
Categories: Governance

0 Comments

Leave a Reply

Avatar placeholder

Your email address will not be published. Required fields are marked *