Reference
Policies for Power Apps
See the Power Apps inventory reference for the objects these templates work on.
| Policy | Description | Severity | Category | Checks |
|---|---|---|---|---|
| Power Apps requiring a premium license ⭐ | Shows Power Apps with premium connectors, custom connectors, common data service etc. Canvas apps using premium, custom, or Dataverse connectors require a per-user or per-app premium license for every consumer. Without proper licensing these apps stop running at scale once the trial grace period expires and create unbudgeted costs. Review the connectors each app relies on, decide whether the business value justifies premium licensing, and either purchase the appropriate plan or refactor the app to use only standard connectors. | Information | Costs | Power App (Canvas App) |
| Power Apps (Canvas Apps) without Owners | Shows PowerApps with no Owners Canvas apps without an owner are orphaned and cannot be governed when the original maker leaves or changes role. Without a responsible owner there is nobody to approve changes, respond to incidents, or decide when the app should be retired. Assign an explicit owner to each app and consider blocking new app publication until ownership is set. | High | Operation | Power App (Canvas App) |
| Power App connections that bypass consent ⭐ | Connections with ByPassConsent skip prompting end users for consent before sharing credentials. Connections with ByPassConsent enabled silently use the publisher's credentials for every consumer, removing the user-consent step that normally protects shared credentials. This effectively turns the connection into a service account with no audit trail of who used it for what. Disable ByPassConsent unless the connection points to a service account explicitly approved for shared use. | High | Security | Connection |
| Custom Power App connections ⭐ | Custom connectors expose external APIs and need to be reviewed for security and authentication. Custom connections call APIs outside Microsoft's first-party governance and bypass DLP classification by default. Without explicit review they can quietly route business data to unsanctioned external services. Audit the destination, authentication method, and DLP classification of each custom connection, and remove the ones that do not meet your standards. | Medium | Security | Connection |
| On-premise Power App connections ⭐ | On-premise connections route Power App traffic through customer-managed gateways and require monitoring. On-premise connections route Power Platform traffic through a customer-managed gateway, extending the corporate attack surface into the cloud apps that use them. They also depend on the gateway's availability and the credentials configured on it. Confirm the gateway is patched and monitored, validate the credentials in use, and migrate to native cloud data sources where the on-premise dependency is no longer necessary. | Medium | Security | Connection |
| Connections using a premium API tier | Premium tier connectors require premium licenses for every consuming user. Premium-tier connectors require a premium license for every user who consumes them. Surfacing premium connections early in the inventory makes it easier to predict licensing costs and avoid surprises at audit time. Review the consumers of each premium connection, decide whether the workload justifies premium licensing, and refactor to standard connectors where the premium tier is not strictly required. | Information | Costs | Connection |
| Custom connectors without a backend service URL ⭐ | Connectors registered without a backend URL are misconfigured and will fail at runtime. Custom connectors registered without a backend service URL are misconfigured: they cannot reach an upstream API and will fail at runtime for every consumer. They typically indicate an abandoned setup or a connector imported from a different environment. Either complete the configuration with the correct backend URL or delete the connector to keep the inventory clean. | Medium | Operation | Power Apps Custom Connector |
| Custom connectors without maintainer contact | Custom connectors without a documented maintainer contact are harder to govern when they break or are misused. Custom connectors without documented maintainer contact information are hard to govern when they break or are misused, because there is nobody obvious to escalate to. The connector ends up either neglected or removed without notice. Require connector authors to fill in the contact properties before publishing, and reach out to authors of existing connectors to backfill the information. | Information | Operation | Power Apps Custom Connector |
| Custom connectors without a license declaration | Custom connectors without a license cannot be reviewed for legal use. Connectors without a declared license cannot be reviewed for legal use, particularly when they wrap third-party APIs that have their own license terms. Without this metadata you do not know if redistribution or extended use is permitted. Ask authors to set the license property and review any connectors that wrap external APIs against the upstream license terms. | Information | Operation | Power Apps Custom Connector |
| Custom connectors without a privacy policy ⭐ | Custom connectors should declare a privacy policy URL so end users understand how their data is handled. Custom connectors without a privacy policy URL leave end users with no information on how the connector handles their credentials and data. This is a governance and compliance gap, particularly for connectors used by external or regulated audiences. Ask the connector author to add a privacy policy URL pointing to the relevant documentation, and reject new connectors that ship without one. | Information | Security | Power Apps Custom Connector |
| Custom connectors classified as Premium | Premium-tier custom connectors require premium licensing for every consumer. Custom connectors classified as Premium require premium licensing for every consumer. Surface these connectors so the cost is visible before they are widely adopted. Confirm the Premium classification is intentional, plan the licensing impact for the expected consumers, or reclassify the connector if the Premium tier is not strictly required. | Information | Costs | Power Apps Custom Connector |
| Custom connectors not updated in 365 days ⭐ | Custom connectors that have not changed in over a year may rely on outdated upstream APIs. Custom connectors that have not been updated in over a year are likely calling outdated upstream APIs and may break without notice when the vendor changes their schema. They also accumulate technical debt that nobody owns. Reach out to the listed maintainer, refresh the connector against the current upstream API, or retire it if it is no longer in use. | Information | Declutter | Power Apps Custom Connector |
| Custom DLP connector not blocked ⭐ | Custom connectors classified as Business or Non-business in a DLP policy can move organizational data to arbitrary endpoints. A custom connector that a DLP policy classifies as Business or Non-business (rather than Blocked) can be used alongside other connectors in the same group, including with business data. Because makers can point a custom connector at any endpoint, this is a classic data-exfiltration path. Review each custom connector, confirm the endpoint is trusted and the business need is real, and move it to the Blocked group (or restrict it with advanced connector policies) if it should not carry organizational data. | Medium | Security | Power Platform DLP Connector |
| DLP policy covers all environments but blocks no connectors ⭐ | An all-environments DLP policy without blocked connectors offers no real protection. A DLP policy that covers every environment but blocks no connectors looks reassuring on paper but provides no actual data-loss protection. It typically indicates an unfinished rollout where the policy was created but the connector classification was never completed. Decide which connectors are not business-approved, add them to the Blocked group, and re-test the policy before relying on it. | High | Security | Power Platform DLP Policy |
| DLP policies defaulting connectors to General ⭐ | Policies that default new connectors to the non-business (General) group inadvertently approve every new connector for general use. Policies that default new connectors to the non-business (General) group automatically approve every new connector Microsoft ships for general use. New connectors then become available without an explicit governance decision and can sit in apps unnoticed. Change the default to Blocked or Business, and classify connectors explicitly as they are needed. | Medium | Security | Power Platform DLP Policy |
| DLP policies with no blocked connectors | Policies that do not block any connector cannot prevent sensitive connector combinations. A DLP policy without any blocked connectors cannot prevent sensitive combinations of business and non-business connectors in the same app or flow. The policy ends up only constraining where connectors can be combined, not whether they can be used at all. Identify the connectors that should never be used in this scope, add them to the Blocked group, and communicate the change to makers before enforcement. | Information | Security | Power Platform DLP Policy |
| DLP policies without custom connector restrictions ⭐ | Policies that do not explicitly classify any custom connector leave tenant-built connectors unrestricted. Policies that do not explicitly classify custom connectors leave tenant-built connectors unrestricted, so a maker can create a custom connector to any endpoint and immediately use it alongside business data. This is a common DLP-bypass pattern in mature tenants. Configure custom-connector restrictions on the policy — either allow-list specific connectors or block all custom connectors — and review existing custom connectors against the new rule. | Medium | Security | Power Platform DLP Policy |
| Default environment used for production ⭐ | Microsoft recommends moving production workloads out of the Default environment to dedicated Production environments. The Default environment is open to every licensed user in the tenant and cannot be governed like a dedicated Production environment. Hosting production workloads there means anyone can create apps and flows that share its data sources, and there is no clean migration story. Create dedicated Production environments with proper security groups, move the workload, and use the Default environment only for personal productivity apps. | Medium | Operation | Environment |
| Power Platform environments not modified for 180 days ⭐ | Environments without recent activity should be reviewed and possibly decommissioned to reduce capacity usage. Environments without modifications in the last 180 days are usually leftover from POCs or departed teams but continue to consume Dataverse capacity, default DLP coverage, and admin attention. Confirm with the environment maker that the workload is gone, back up anything still needed, and decommission the environment to reclaim capacity. | Information | Declutter | Environment |
| Inactive Power Pages sites ⭐ | Power Pages sites with status Inactive are not serving traffic and may be candidates for cleanup. Power Pages sites in the Inactive state are not serving traffic and consume capacity without delivering value. They typically remain after a project ends without a formal decommission. Confirm the site is no longer needed, export any content worth keeping, and delete the site to free up capacity. | Information | Declutter | Power Pages Site |
| Production Power Pages sites without a custom domain | Production sites served only from the default powerappsportals.com subdomain look unbranded and lack DNS-level control. Production Power Pages sites served only from the default powerappsportals.com subdomain look unbranded to external users and lack DNS-level control, which limits options for SSL, traffic management, and migration. Configure a custom domain with appropriate DNS records and SSL, and update marketing materials to reference the branded URL. | Information | Adoption | Power Pages Site |
| Power Pages sites not updated in 90 days ⭐ | Sites untouched for 90+ days may be abandoned. Review whether they are still required. Sites untouched for 90+ days are usually no longer maintained, which means content drifts and security updates are not applied. Stale public sites also become a reputational risk. Check with the listed owner whether the site is still required and either refresh it or decommission it. | Information | Declutter | Power Pages Site |
| Suspended Power Pages sites ⭐ | Sites in the Suspended state are blocked by Microsoft; investigate and unblock or remove. Sites in the Suspended state have been blocked by Microsoft, typically for policy violations, abuse signals, or billing issues. They are not serving traffic but the underlying problem is unresolved. Investigate the suspension reason in the Power Platform admin centre, remediate the cause, and either restore the site or delete it once the data is exported. | High | Operation | Power Pages Site |
| Power Pages sites on a trial ⭐ | Trial sites expire and cannot be relied on long-term. Convert to production before content is built on top. Trial Power Pages sites expire and cannot be relied on for long-term content. Building production workloads on top of a trial site leads to either a forced migration under time pressure or a service outage when the trial ends. Convert trial sites that host real content to a production plan, or schedule their decommission well before the trial expires. | Medium | Costs | Power Pages Site |
| Power Apps that bypass user consent ⭐ | Apps with BypassConsent skip the connector consent prompt and silently use shared credentials. Apps with BypassConsent silently use the connection credentials of whoever published them and never prompt end users to consent to data sharing. This violates the explicit-consent expectation customers have for Microsoft 365 apps and exposes the publisher's credentials to every consumer. Turn off BypassConsent unless there is a documented business justification and the connections in use are service accounts approved for shared use. | High | Security | Power App (Canvas App) |
| Power Apps inactive for 90+ days ⭐ | Apps that have not been modified for 90 days are likely no longer maintained. Apps that have not been modified in 90 days are likely no longer actively maintained, which means broken connectors or breaking API changes will not get fixed. Inactive apps also clutter the maker portal and pull on licensing capacity. Reach out to the listed owner to confirm the app is still required, and archive or delete the ones that are not. | Information | Declutter | Power App (Canvas App) |
| Power Apps not published in the last year ⭐ | Apps that have not been republished in over a year may be abandoned and ready for decommission. Apps that have not been republished in over a year are typically abandoned: the maker has moved on, the underlying data sources have shifted, or the workload has been replaced. Keeping them in inventory wastes licensing capacity and confuses end users who still discover them. Confirm with the owner whether the app is still in use, then either republish or decommission it. | Medium | Declutter | Power App (Canvas App) |
| Solutions owned by the default publisher ⭐ | Content shipped under the environment default publisher cannot be versioned or distributed cleanly. Assign a real publisher with a customisation prefix. Content shipped under the environment default publisher cannot be versioned or distributed cleanly between environments, and ends up entangled with every other maker's customisations. This breaks ALM and makes solution migrations brittle. Create a real publisher for the solution with its own customisation prefix and re-import the components against it. | High | Operation | Power Platform Solution |
| Solutions with no components | Empty solutions add governance overhead without packaging anything. Remove or merge them. Empty solutions package nothing but still appear in every environment they are imported to, where they create governance and migration overhead for no benefit. They usually indicate a deployment mistake or an abandoned scoping exercise. Confirm the solution is not a placeholder for in-progress work, then delete it. | Information | Declutter | Power Platform Solution |
| Solutions without a publisher prefix | Solutions whose publisher has no customisation prefix produce uncategorised entities and fields. Configure a publisher prefix before packaging content. Solutions whose publisher has no customisation prefix produce uncategorised entities and fields that collide with other solutions. The resulting naming clashes make ALM and support harder. Configure a meaningful publisher prefix before packaging content, and rename any existing components that were created without one. | Medium | Operation | Power Platform Solution |
| Solutions without an identifiable owner | Solutions with no recorded creator are unowned and cannot be assigned for governance follow-up. Solutions with no recorded creator are unowned and cannot be assigned for governance follow-up. When the underlying components break or need updating there is nobody to escalate to. Identify the responsible maker or team for each solution, populate the ownership metadata, and remove orphan solutions that nobody is willing to claim. | Medium | Operation | Power Platform Solution |
| Solutions not updated in 365 days ⭐ | Solutions untouched for over a year are likely stale. Review whether they are still in use. Solutions that have not been updated for over a year are typically no longer actively maintained, even if the contained apps and flows still run. Keeping stale solutions in inventory hides ALM problems behind apparent calm. Review with the listed owner whether the solution should still ship, refresh it against the current development environment, or retire it. | Information | Declutter | Power Platform Solution |
| Unmanaged solutions ⭐ | Unmanaged solutions are editable in place and undermine ALM. Shipping content should be packaged as managed solutions. Unmanaged solutions are editable in place in every environment they reach, which makes them incompatible with proper ALM and difficult to roll back when a deployment goes wrong. They are an early-stage development artifact, not a release vehicle. Package shipping content as managed solutions exported from a dedicated development environment, and treat unmanaged solutions as work-in-progress only. | Medium | Operation | Power Platform Solution |
| Power Apps (Canvas Apps) shared with everyone | Shows Power Apps that all users of current tenant can viewed and used. Apps shared with the entire tenant expose every connection embedded in the app to every signed-in user, which often includes service-account credentials and shared API keys. This is rarely the intended sharing scope and creates a substantial data-leakage and consent risk. Replace tenant-wide sharing with explicit Microsoft 365 groups, audit the connections used, and revoke the share where the broad audience is not required. | Information | Security | Power App (Canvas App) |
| Power Apps shared with more than 100 users | Apps shared with very large groups of users should be evaluated for tenant-wide sharing or governance. Apps shared with very large groups of users behave like tenant-wide deployments and warrant the same governance scrutiny: connection-credential sharing, performance impact, and license consumption. A high share count often signals that an everyone-style share should be made explicit or that the workload should be moved to a managed solution. Review the audience, verify it matches the data classification of the app, and tighten the share if appropriate. | Information | Security | Power App (Canvas App) |
| Power Apps using custom connectors ⭐ | Apps using custom connectors bypass first-party connector governance and must be reviewed. Custom connectors call external APIs outside Microsoft's first-party connector governance and bypass DLP classification by default. Without review they can leak business data to unsanctioned endpoints. Inventory the custom connectors each app uses, validate the destination, authentication, and DLP classification, and remove or replace connectors that do not meet your standards. | Medium | Security | Power App (Canvas App) |
| Power Apps relying on grandfathered premium APIs ⭐ | Apps still using grandfathered premium connectors will eventually require premium licenses. Apps still relying on grandfathered premium connectors are running on a Microsoft licensing exception that will eventually be withdrawn. When it is, every consumer will need a premium license or the app will stop working. Identify a migration path now — either purchase the appropriate premium licensing, refactor to standard connectors, or replace the app — so the change is not forced under time pressure. | Medium | Costs | Power App (Canvas App) |
| Power Apps using an on-premise data gateway ⭐ | Apps reaching on-premise data sources increase the attack surface and depend on gateway availability. Apps reaching on-premise data sources through an on-premise data gateway extend the corporate attack surface into the Power Platform and depend on the gateway's availability. A misconfigured or unmonitored gateway can become a backdoor into internal systems. Review the gateway configuration, the credentials it uses, and the apps relying on it, and migrate to native cloud data sources where possible. | Medium | Security | Power App (Canvas App) |
| Power Apps without a description ⭐ | Apps without a description are harder for end users to discover and for admins to govern. Apps without a description are hard for end users to discover and for admins to triage during inventory cleanups. Without context the app is often duplicated by another maker and the original is left to bit-rot. Ask makers to add a short description explaining the purpose, audience, and data sources for every published app. | Information | Operation | Power App (Canvas App) |