The Enabling Technologies Blog

Our team of Cloud Strategy Advisors, Solution Architects, Engineers and former C-Suite Executives work diligently to provide our vistors with the most pressing information.

Chris Stegh /

Leakage Shows Need for PowerApps Governance

Up until a research firm found 38M records publicly exposed in 47 customers’ PowerApps portals, Microsoft’s default settings permitted public access to the data by default. The default has since changed due to this research (see #4 below), but it begs the question… Who plans, secures, and monitors low-code apps developed by citizen developers?


Low-code applications and robotic process automation have caught fire! Enabling’s PowerApps customers include CFOs, operations leaders, departmental chair-people, non-tech types. But with ease of use comes risk. Apps can be created then orphaned, expose too much data, and might connect to other systems insecurely.

Power Platform-1

What should an organization do to follow best practices?

  1. Set Expectations

People have big ideas, but they should start small. Get them started by optimizing their own personal workflow rather than creating an app for the department or enterprise. The simplest ways to wet their beak are Flows and Dataverse for Teams

An inexpensive way for citizens to build a multi-user PowerApp is to create an app in Teams using the Dataverse for Teams. It’s a limited version of Dataverse, but way better than using SharePoint lists, and the price can’t be beat (free under most Office 365 A3/E3/G3 skus). Having citizens create their own automation using Dataverse for Teams app forces them to do two important things.

a. They must define their dataTeams dataverse
b. They must define their process

Doing both is a win/win. They get something working quickly, and if the app proves valuable enough for other groups, then the pro developer already has the structure and requirements they usually struggle to define. Note, once the app is published in a specific MSTeam, it’s stuck there. If it needs to be exposed to others outside of that Team/Channel, the others need to be added to that Team/Channel, or, painfully, the app needs to be recreated as a fully-featured PowerApp, the data mapped and imported, and be licen$ed accordingly.

Make citizens aware that their initial work is for themselves and/or their workgroup. Call them prototypes, or betas. Reinforce this by changing the name of the default Power Apps Environment to “Personal Productivity (default).” This name shows up at the top of their PowerApp homepage. This name infers that the default environment is the preferred place to start building personal productivity apps. When apps catch fire across an org, they’re often rebuilt by the pro developers.

  1. Set and Ensure Standards

“It’s all about me!” Citizens usually start with a laser focus on their immediate problem, not the extensibility of their app. But getting them to begin with the end in mind will save rework, security risks, licensing costs, and frustration.

One of the first standards to address is user access. Who needs to access the app? Do they authenticate? Canvas apps are easy to create but are limited in how they can be published. Currently, they are only accessible to users authenticated by Azure AD (AAD). If the target users are outside of the developer’s AAD, then those users need to be added as guests in the host organization’s AAD. An app might work internally, but not for Internet facing users. Decisions about user access also affect *gulp* licensing.

Other areas to standardize are default settings, documentation templates, and yes, security.

  1. Don’t accept the defaults!

To fix the issue relayed at the top, MSFT said, “Starting with release 9.3.7.x, newly created portals will have table permissions enforced for all forms and lists irrespective of the Enable Table Permissions setting. Also, with the same release, lists on all portals (new or existing) that have OData feeds enabled will require appropriate table permissions setup for the feed on these lists to work.”

This could render some lists inaccessible if they are not altered. Table configurations can still be changed to allow for anonymous access, but manually and only when needed.

There’s also a tool for checking Power Apps portals and planned changes to the product so that table permissions will be enforced by default. Analyze and resolve Portal Checker diagnostics results - Power Apps | Microsoft Docs Use that Portal Checker to detect lists that allow anonymous access.

  1. Secure in Layers

Multiple layers make up the security model of the Power Platform:

  1. Users are authenticated by Azure Active Directory (AAD), and can be restricted with conditional access policies and MFA.
  2. Licensing controls access to Power Apps components. No license, no access.
  3. The ability to create applications and workflow is controlled by security roles in environments.
  4. Power Apps have to be shared with the user in order to see or use them. Power Apps canvas apps are shared either directly with the user or AAD group. Model-driven apps are shared by assigning the user the appropriate Common Data Service security role.
  5. Environments act as security boundaries allowing different security needs to be implemented in each environment.
  6. Power Automate flows and canvas apps use connectors. The specific connections credentials and associated service entitlements determine permissions when apps use the connectors.
    Power App Environments
  7. Environments with a Common Data Service (CDS) instance have specific controls for access to data and services in that CDS instance.
  8. You can define who is allowed to use what data and for purpose. Data loss prevention (DLP) policies can act as guardrails to help prevent users from unintentionally exposing organizational data. DLP policies enforce rules for which connectors can be used together by classifying connectors as either Business or Non-Business (and recently, “Blocked”). Cross-tenant inbound and outbound restrictions can also be applied to the connectors.

       5. Provide Training

Even citizen developers should get training, either through a formalized program like UIpath or Microsoft Get started with Power Automate - Learn | Microsoft Docs, or informally through the SMEs at Enabling, who can train as developers learn on the job. No matter what the external training source, the key is to ensure everyone is given Internal training on security principles and standards, before they get officially certified to provide corporate-wide apps or connect to enterprise data.

  1. Control License Costs

It may be easy for a citizen to create an app, but scaling as a departmental or enterprise app is not so trivial.

As usual, MSFT has made PowerApp licensing a convoluted piece of… “work.” Put simply:

  • The aforementioned Teams Dataverse apps are free with some E3/A3/G3 skus.
  • Users of one Canvas app pay $10/month.
  • Users on run two or (up to) unlimited applications with full capabilities pay $40/user/month. Yes, that’s per user (not per developer). You can see why it’s important for the COE to set expectations about how developers would ideally create apps.

The questions to ask that affect licensing and costs include:

  1. Is a per user or per app license more cost effective?
  2. What add-on capacity is needed? E.g. Portal Page Views, AI credits
  3. How much storage capacity is needed? For database, files, logs

Once the COE understands the options, an org-wide standard should be shared with new devs as they complete their training.

  1. Supporting Citizen Developed Apps

When citizens develop their personal or departmental app, and it breaks, who gets the call? The Help Desk needs to at least know the ‘Owner’ of the app to escalate.

If the COE decides to publish an app for multiple departments or Teams, enterprise-level SLAs are necessary. If an app matures to this point, the COE or professional development team will likely rebuild the app according to enterprise standards and support models.

As the user base grows, and apps became more complex, every change will require more quality control. The COE should set up a role-based model where only a few citizen developers who fully understand the impact of changes can publish new iterations.

Like pro developers (sorry guys), citizens will not keep meticulous revision notes, at first. This will cause problems when rolling back to a prior version after a change doesn’t go as planned. Citizens should do regression testing and have a plan revert a change. Having notes that explained what changed in each iteration will identify which version introduced the change.

Multiple apps can be deployed in a single environment. This is most common with dev/test/prod using the same Dataverse in the environment. But if apps share data from the same Dataverse, they can conflict. To keep things simple, it’s best to have an app use its own Dataverse and be in its own environment.


Microsoft’s PowerApps are already in the Leader’s Quadrant, but the defaults, security controls, and development standards can run amok if not owned and monitored by the COE.

Key takeaways include:

  • Create the COE and standards for environments, security, and update management.
  • Set citizen and user expectations about the (lack of) support model for personal or Teams/Channel apps. Plan to rebuild apps that are promoted to multi-Team/department use.
  • Provide training about the standards and how to properly build apps with the least licensing cost.
  • Secure the access, access to configurations, and data of the app and connectors.
  • Don't leave the defaults!

PowerApps Magic Quadrant

Enabling’s PowerApp consultants can provide education for your COE and Pro Developers to successfully get your governance model under control. Ping us anytime!

Work with our team of Cloud Computing Consultants who have done this so many times they know all of the “minefields” to prevent missteps.

Tags: PowerApps