App out of control! How Power Platform governance can help mitigate risks in low-code solutions

Low-code governance can sound like an abstract concept. Even IT professionals with experience from managing either SaaS services or custom developed software can have a hard time describing what governance means in practice when applied to Microsoft Power Platform. This is understandable, given how many differences there are between traditional enterprise IT and the solutions that today’s low-code platforms make possible.

In this blog post I will use an example from the real world to describe what issues your low-code governance policies should aim to address. I will demonstrate the kind of negative impact that an ungoverned app may have in practice, for both the business users and IT. Hopefully this will help in justifying why setting up guardrails for the use of tools like Power Apps and Power Automate is necessary in every organization wanting to reap benefits from their growing usage of low-code technology.

The scenario that we’ll talk about is an application that was developed and taken into production use before a Power Platform governance model was defined for this organization. It had been developed and maintained by an external partner, to meet the requirements specified by the business process owners. It’s important to note that although inexperienced citizen developers are often perceived as the big risk factor in low-code app development, the problems we’re about to cover were discovered in a solution created by professional developers.

Analysis of one Power Apps solution

As we started to analyze the current state of Power Platform usage in the organization’s Microsoft 365 tenant, by leveraging the CoE Starter Kits tools, we quickly noticed that this specific application was among the most used and most advanced low-code solutions. The business relied on the app to manage its monthly activities for a specific process in one department. On the busiest days, there were over a hundred different users opening the canvas app. On the surface, everything was working as the users expected.

When we took a closer look, though, there were several issues identified in our analysis that potentially could cause disruption to the important business process. In fact, over the next few months there were unfortunately real problems resulting from these issues. This is because once you have accumulated technical and process debt, changing things will often be a long road to travel.

The key areas that we flagged in our analysis were the following:

• Architecture
• Environment strategy
• Security and access management
• Identity management
• Licensing
• Documentation

Next, we’ll go through each of these via examples of what mistakes had been made. We’ll also discuss how similar issues could be prevented in future solution development.

Architecture: what are your building blocks & why?

When professional developers start using tools from Microsoft’s low-code platform, they are often not aware of the full spectrum of services available. Instead, they may pick an individual tool like Power Apps and focus on what it can do – such as quickly building a user interface as a canvas app. While these low-code tools can be combined with pro-dev tools from Microsoft, the end result may not be well thought out or optimal from a maintenance perspective.

In this case the canvas app was storing all its data in an Azure SQL database. There were also a wealth of other services used to support its features, such as Azure blob storage, Azure Data Factory, Azure Key Vault. Although there is technically nothing wrong with leveraging Azure, it seemed like functionality that could have been built using native low-code services like Dataverse had been implemented the pro-code way.

What’s the problem then? If you are using Azure to replace Power Platform services instead of augmenting them, you can’t take advantage of the platform part to its full extent. For instance, solution packages that would allow you to easily move the different Power Platform components from one environment to another in your deployment process can’t include any resources in Azure. Even the Power Platform environment boundaries don’t apply in Azure, meaning you’ll have to maintain your development, test and production artifacts separately in two clouds.

How should your low-code application platform governance model address this? Application Lifecycle Management (ALM) is something that developers should consider already before starting to build the solution. The architecture choices made between low-code vs pro-code shouldn’t be based solely on what tools are most familiar to the developer. Therefore, you need high-level guidance that will make everyone think about these consequences when designing their Power Platform solutions.

Another key point is in ensuring that the required resources are available to the developers. If it is easier for a person to request and gain access to Azure resources than getting the necessary Power Platform premium features unlocked – guess which one they’ll prefer? Your governance processes should make it clear to every potential app maker what IT resources they can acquire and how. Otherwise, they’ll just work with what they know how to get, to meet the external pressure for deployment deadlines.

Environment strategy: where are you building & running your apps?

This leads us to the next big topic. Power Platform environments are the container for all the resources used in low-code solutions. This is why your environment strategy is arguably the most important part of your low-code governance model.

Everything that happens with Power Apps, Power Automate flows, Dataverse tables, connectors – it all takes place inside an environment. These same environments also define the perimeter for the technical enforcement rules you put in place for data, users, and so on. Therefore, if things get built into the wrong environment initially, you are likely incurring technical debt.

In our scenario, the app was running in the worst possible place: the Default environment of the tenant. Without going into details here, important business processes with 100+ monthly users should never have their app deployed in the Default. Yet it is the place that is available to all makers by design, so this is where far too many apps and automations end up in ungoverned tenants.

Since there was no process in place that would have allowed developers to easily request proper Power Platform environments for their solutions, everything was running in Default. And by everything, I mean there was nothing but the production version of the app – anywhere. No development or test versions existed. This of course applied to the components outside Power Platform as well, meaning the many Azure resources the app depended on. As any IT professional will know, “testing in production” is a great recipe for disaster.

Power Apps canvas app studio has a built-in feature for managing the app’s version history. From there we could see that 300+ versions had been published over the course of 3 years. Unfortunately, these won’t be of any use if they are older than 6 months, due to how Microsoft enforces the allowed versions of the Power Apps runtime bits. No offline copies of the app were discovered – nor the flows, let alone the several Azure components. What happens when you accidentally change something?

Your Power Platform governance model should obviously address these kinds of shortcomings by stating what is required from apps and automations that go beyond personal productivity. The production and non-production environments that should be used, building everything by leveraging the solution framework, ensuring that sufficient version control is in place. Neglecting these rules for any apps that end up in broad production use needs to have clear repercussions – otherwise people will keep cutting corners under time pressure.

Security and access management: who’s got the admin rights to data?

One reason why Power Platform environments are so central in governing your low-code solutions is their role in data security and user access management. If you are building things in Default, you are very limited in what is technically possible to achieve on this front. This is because every licensed user can build apps and automations there, just with their Office 365 / Microsoft 365 license.

As mentioned earlier, our example application was storing all its data in an Azure SQL database. “Great, so at least it’s not physically in that Default environment.” Not so fast. It turns out that the data was actually less secure because of this architecture choice. This is due to how the app’s connection to the database was managed.

With what is called “implicitly shared connections”, the authorization for SQL data access was performed using credentials stored in the connection used by the app. When the app was shared to users, also this connection was shared to them – so that the app could read and write SQL data. Unlike Dataverse that could use the currently logged in user’s identity and the assigned security roles, every user of this app was effectively using SQL as an admin level user. The Power Apps UI only allowed a subset of actions to be performed by the users. Yet in this scenario you can’t rely on UI level limitations to be sufficient.

The real risks of such implicitly shared connections start to materialize once the makers create new apps in the Default environment. If any of the 100+ users of the app had decided to reference that existing SQL connection in their own app, they could have bypassed any UI level “security” mechanisms. I have to say, when I validated this in the customer’s environment and created an example app with a delete button tied to the actual Power Fx function for screenshot purposes, my hands were shaking a bit. (Remember: there’s nothing but the production app & database to test this in.)

Obviously, a scenario like this must be technically blocked as part of your Power Platform governance model. Data Loss Prevention (DLP) policies have to be designed and deployed to ensure that connections to services that use such shared identities (including API keys) cannot be created in the Default environment. A production environment for such apps needs to have limited maker/admin rights for those who perform deployment related activities. Every normal user must only have access to the application UI – not the source code of the solution that exists in the environment.

Identity management: what happens when people leave your organization?

One major benefit of using Power Platform as your enterprise low-code application platform is its tight integration with the existing identities of your users. All the tools for both app makers and users are guarded by the same credentials as your other Microsoft 365 services, without any extra effort required from IT. Microsoft Entra ID (formerly Azure AD) provides additional capabilities like conditional access policies for more granular control when needed.

This convenience of integrated identity across office tools and low-code app development tools can cause challenges, though. Because it is simply too easy to build something that is tied to the personal user account of the developer. Such dependencies are a common source of IT administration work when employees change roles or they leave the organization.

In the example application, everything had been built using the personal identity of an external developer. Not just in Power Platform but also on the Azure side. Things kept working as long as that user account was active and had both sufficient licenses as well as access rights to systems and data. Then came the inevitable moment when the contract ended, and the user account was deleted from Active Directory. Can you guess what happened after that? I can tell you that the first symptoms of Power Automate cloud flows failing were just a start…

Your Power Platform governance model must address the natural lifecycle of application and automation developer identities. Nothing that should keep working after a person leaves the organization can be dependent on the user account of that person. Instead you must have a process for acquiring and assigning identities like service accounts or service principals (SPN) for all such resources.

Trust me on this: it is much easier to assign the ownership to all the related apps, flows, connections etc. right at the start when deploying the solutions to test and production environments. If you only discover the dependencies to individual user identities once the flows stop working and connections to data sources give errors, you will have a bunch of support tickets to keep you busy for a while.

Licensing: have you ensured your app usage is compliant with the commercial terms?

The one area that not many developers or even Power Platform low-code professionals are particularly comfortable talking about is Microsoft’s licensing model. It is true that the intricacies of low-code platform licensing can be quite complex to master. Yet it is absolutely crucial that the common concepts of how products like Power Apps & Power Automate are paid for is explained to all the makers. Otherwise, you’ll run into nasty surprises that are much more uncomfortable than the tricky terminology in the Power Platform licensing guide.

The application in question was a canvas app that didn’t leverage a premium feature in Power Platform like the Dataverse. However, it used several premium connectors in order to connect to the Azure services where the data was stored and processed. As a result, every end user of the application was contractually required to have a Power Apps Premium license (formerly Per User). There were no Per App licenses assigned to this environment so that option was out.

When we discovered the relatively high number of users to whom the app had been shared to, we opened the details of a few M365 user accounts to check their licensing details. It turned out that a wealth of users only had the rights for Power Apps standard features and connectors that come with their Office licensing. They did not have the premium license required to use this particular app.

How was this even possible? It is because we cannot rely on the technical enforcement of the licensing model limits to be applied in each corner of the Power Platform. Even though much of the latest functionality has a built-in wall to block the free usage of premium features, especially with older solutions there may be gaps that do not prompt users if they are missing a license. In this case, the app showed the “premium diamond” icon in its settings, yet runtime enforcement was lacking.

This example emphasizes the need for proactive evaluation of the types of licenses needed for a solution – much before it reaches broad production use. Your Power Platform governance processes need to have sufficient gates in place where the resource requirements of an app, bot or automation are reviewed. Do keep in mind that the development work of a Power Platform solution can often be performed without a Premium license – yet the users who gain business value from it must be properly licensed. A quick demo app or PoC that validates the technical capabilities does not yet guarantee the solution has a valid business case if its license costs are ignored.

In organizations or teams where the user base already has existing Power Apps or Power Automate Premium licenses acquired and assigned, the cost impact requires less analysis for each planned solution. At that point of your Power Platform adoption journey, it will be possible to scale the usage of premium capabilities and reap the growing benefits from having one user license that covers an unlimited number of business applications.

Until you get there, though, be sure to pay attention to the cost factors of the different resources. Set up the necessary monitoring processes to ensure you always remain compliant with the licensing terms. By doing the basic things right, there’s little reason for concern if a license audit should happen on your duty.

Remember that with Power Platform you are essentially replacing the work hours needed for developing custom code with cloud-based tools that deliver similar functionality as a configurable service. It’s not meant to be “free to use” because it should deliver real business value to your organization in exchange for these licensed services. If the practical outcome of your governance process ends up blocking everyone from using any premium features in Power Platform, it’s time to revisit your organization’s strategy for low-code & citizen development and ask: “why were we doing this again?”

Documentation: do you know where to look when things stop working?

Often it is the very last thing on the developer’s To-do list: “write the documentation”. Some might consider the act of documenting their solution as tedious as figuring out what Microsoft licenses and resources are needed for using it. From a governance perspective, this natural resistance towards the topic means the Power Platform owners, admins and CoE team need to pay special attention to it.

We’ve gone through five different pitfalls already with our example application. The common denominator for them all is that identifying the issues in each of them beforehand would have been at least theoretically possible – if there was any documentation. Well, by now you’ll have guessed that there was nothing to be found. Which is why resolving the issues took a lot longer and thus cost more work hours for the organization, both in the direct technical tasks as well as lost productivity due to downtime and errors in the app.

Even though the app was developed by a professional, with technical skills for using both Power Platform and Azure services, the solution turned out to be really challenging to maintain due to this lack of documentation. Just because there is less “real code” to be reviewed on the Power Apps and Power Automate side, that doesn’t remove the need for understanding how the different components of the solution relate to one another. Especially given the integration with services on the Azure side.

Like the area of identity management, documentation is all about removing the dependencies between a system and its original creator. Separating the app maker as an individual from the process of maintaining and supporting the app is a big step to take – especially in the citizen developer model. You can’t expect these individuals to just figure out the right thing to do on their own. Often the makers themselves would want to be able to move on and not be forever responsible for maintaining everything they’ve built. For this to happen, your organization needs to formulate a model that makes it both possible and realistic.

Only your imagination is the limit to what could be developed using the Microsoft Power Platform. Therefore, it isn’t necessarily useful to try and define on a very detailed level how each solution must be documented. Instead, from a governance model perspective, you should first aim to establish a format in which you capture the core attributes of any solution requiring attention and activities from the IT. Use this as one of the evaluation gates in your process early enough to engage with the makers and steer them towards the right path in accordance with your Power Platform governance model.

Closing thoughts: taking ownership of your low-code platform

When we talk with customers for the first time about the state of their Power Platform usage, it is quite common that the answer is “we don’t really know”. The reality is that for a typical organization using Microsoft 365 tools and possibly also Dynamics 365 business applications, there usually has not yet been a clear ownership established for Power Platform. Its many technologies can be widely in use already – because they don’t need to be specifically deployed by IT.

It’s a natural step in the adoption journey for Power Platform where it may feel like things are running out of control. Awareness of the fact that you need to do something to get things better under control is already a positive signal. There are plenty of tools available both in the platform itself as well as in the community that can help you perform the technical analysis of what has been built and what is in use.

Just don’t expect technology to solve all your problems. While you can implement some technical policy enforcement and monitoring via Power Platform product features, the majority of the work will be in building up the processes and communication channels for your app makers, users, owners, IT admins and other stakeholders to turn governance models into governance practices.

Getting things in their right place will take time, especially with apps like the one we analyzed in this article. Since you very rarely are starting from a clean slate, there’s usually not an option to just “BLOCK ALL THE THINGS!!!” Instead, you must balance the needs of the business users with the target state of IT and work towards an equilibrium. Dialogue with the citizen developers who are passionate about using modern cloud tools to solve real business problems is often the best investment of time you can make in driving your organization’s digital transfromation in practice.

At Forward Forever, our team has been working with organizations of various sizes and industries that want to take true ownership of their digital tools. Throughout the past few years, we’ve fine-tuned our model for Power Platform governance advisory services based on real-life experiences. The way we help our customers establish a healthy state of low-code application platform governance consist of these 3 steps:

• Current state analysis of what apps & automations have been built on the Power Platform & what are the most critical governance issues to address first.
• Power Platform governance training for the stakeholders, so that everyone understands the key technical factors at play in low-code solution development and usage.
• Planning and documenting how the platform will be governed in the organization, based on Forward Forever’s Power Platform Governance Framework.

If you’re interested in learning more about our Power Platform governance services, reach out to us via the contact form or get in touch with Antti Pajunen / Jukka Niiranen directly.