Why successful Power Apps pilots can become operational risks
A purchasing approvals app works exactly as intended. Employees submit requests, managers approve them, and hours of administrative work disappear. The pilot is declared a success.
Then the application rolls out across departments, and nobody is quite sure who is responsible when something goes wrong.
Why does Power Platform governance fail after a successful pilot?
Power Platform governance often fails because applications become business-critical before the organisation establishes the controls needed to operate them reliably. A successful Power Apps pilot proves that a solution can perform a task. It does not establish who owns the application, how sensitive information is protected, whether dependencies are reliable or how the business will recover when something fails.
Low-code accelerates development. It does not eliminate operational responsibility.
That distinction becomes significant as adoption grows.
The risks emerge when the business starts depending on the app
Consider an approvals application initially developed for a small purchasing team.
During the pilot, its creator can monitor requests, correct errors and resolve issues personally. Expanding the application introduces different conditions.
More employees need access. Approval limits become more complex. Financial information requires appropriate permissions. Power Automate flows may depend on connections managed by individual employees, while purchasing records need to remain consistent with systems such as Dynamics 365 Business Central.
A failed connection could now delay purchasing decisions or leave approvals incomplete. If the original developer has changed roles, identifying the cause and restoring the workflow becomes harder.
The application has not necessarily become poorly designed. Its operational importance has outgrown the arrangements supporting it.
These concerns are recognised beyond individual implementations. Gartner’s May 2024 research abstract, 50 Best Practices for Governing Microsoft Power Apps and Power Automate, identifies application sprawl, data leakage, misuse and orphaned solutions among the risks associated with inadequate governance.
The business implication is straightforward: application development can move faster than the organisation’s ability to govern and support what it creates.
Production readiness starts with business criticality, not technical completion
Before expanding a Power App, establish what the business stands to lose if it becomes unavailable.
An internal team utility and an application authorising supplier expenditure should not automatically face identical requirements.
Assess the sensitivity of information processed, the consequences of interrupted workflows, dependencies on other systems and the acceptable recovery time.
Then establish accountability.
The business owner should be responsible for process requirements and operational priorities. IT should oversee technical controls and service arrangements. Named support contacts must understand how to investigate failures, restore service and escalate unresolved incidents.
These responsibilities should exist independently of the person who originally developed the application.
For GO ERP, this reflects a wider principle of Microsoft business applications delivery: a solution should be designed around the business process it supports, including how that process will operate after deployment.
The real measure of readiness is whether the business can depend on the application, maintain it and change it safely without relying on informal knowledge.
Establishing that confidence begins with identifying the governance gaps most likely to undermine production operations.
Six governance gaps that reveal whether a Power App is ready to scale
A Power App can pass every functional test and still be unsuitable for production. The weaknesses often sit outside the application itself: who controls access, how changes are released, and what happens when an automated process stops working.
The practical starting point is to assess these dependencies before expanding access.
The Six-Gate Power Apps Production Test
GO ERP’s proposed Six-Gate Production Test provides a structured way to assess Power Apps production readiness. Each gate examines a different source of operational risk, connecting weak controls to their business consequences and the action required.
| Readiness gate | Weak control → business risk | Required action |
| 1. Ownership | An app or connection depends on one employee → disruption when that person leaves or changes roles. | Assign business and technical owners; document critical dependencies. |
| 2. Information access | Excessive permissions or unrestricted connectors → sensitive data exposure. | Review security roles, connector permissions and Power Platform data policies. |
| 3. Environment controls | Development changes reach production without adequate separation → unexpected service failures. | Establish appropriate development, test and production controls. |
| 4. Testing | Individual functions pass, but complete workflows fail → incorrect approvals or incomplete transactions. | Test integrations, exceptions and user acceptance scenarios. |
| 5. Support | Failed automations lack monitoring or escalation → unresolved requests and operational delays. | Assign incident owners, monitoring, recovery procedures and escalation routes. |
| 6. Adoption | Employees lack training or clear procedures → workarounds and inconsistent processing. | Validate real-user tasks, training needs and support arrangements. |
Which governance gaps should be fixed first?
Not every weakness carries the same consequence.
An application processing supplier banking information requires stricter access controls than a team scheduling tool. Equally, a failed automation that prevents purchasing approvals deserves greater attention than a minor interface inconvenience.
Prioritise findings according to three levels:
Critical — address before production release. Unauthorised access to sensitive information, missing accountability for a business-critical application or an unresolved dependency that could interrupt essential operations.
High — remediate or formally assess before approval. Incomplete integration testing, insufficient monitoring or weaknesses in recovery arrangements that create material but potentially manageable exposure.
Lower — improve through a documented action plan. Minor usability issues, additional training requirements or non-critical documentation gaps that do not prevent safe operation.
Risk ratings must reflect business criticality and the actual safeguards available. A support weakness that is manageable for one application may prevent another from being released.
Governance should follow the workflow, not just the technology
Consider a purchasing app connected to Dynamics 365 Business Central.
Checking the Power Apps interface alone will not establish whether approval records reach the correct purchasing transactions, whether failed Power Automate runs are detected or whether employees can recover an interrupted request.
The readiness assessment must follow the process across its connected systems.
This is where GO ERP’s Power Platform and Microsoft business applications expertise becomes relevant: assessing applications in the context of their business processes, data dependencies and support requirements.
The six gates identify where risk exists. The next decision is what evidence must be produced before those risks can be accepted and the application released.
How to turn Power Apps governance into a defensible release decision
Identifying governance weaknesses is only useful if the findings influence whether an application goes live.
A production-readiness checklist should turn each requirement into a documented decision: what must work, who must verify it and what happens if the evidence is missing.
What should a Power Apps production-readiness checklist include?
A practical Power Apps production-readiness checklist should cover security, deployment, testing, licensing, recovery and operational handover. Each control needs an accountable owner and evidence that can be reviewed before production access is approved.
| Release control | Accountable owner | Evidence required |
| Security and access | IT security lead | Approved permissions, connection ownership and data policy checks. |
| Application lifecycle management | Technical lead | Version-controlled solution, environment configuration and deployment records. |
| Business-process testing | Business process owner | Signed user acceptance tests covering normal and exception scenarios. |
| Licensing and capacity | Platform administrator | Verified user entitlements, connector requirements and anticipated costs. |
| Recovery arrangements | Technical/support lead | Documented recovery procedure, tested restoration approach and escalation contacts. |
| Operational handover | Service owner | Support responsibilities, monitoring arrangements, training and incident procedures. |
The checklist should reference the actual application and release version, not simply confirm that policies exist.
For example, a successful test of an approval screen provides little reassurance if nobody has verified what happens when its connection to Business Central fails.
Make application lifecycle management part of the approval
Microsoft Power Platform application lifecycle management (ALM) provides a structured approach to developing, testing and releasing application changes.
For business-critical solutions, this typically means maintaining appropriate environment separation, packaging application components into solutions and using controlled deployment procedures.
Power Platform pipelines can support repeatable deployments. Connection references and environment variables help manage differences between environments.
Neither automatically proves that a release is safe.
Testing must establish that connected systems behave correctly after deployment. Recovery planning must address how a known-good version can be restored where feasible, alongside any data corrections or workflow recovery needed.
Who decides whether a Power App can go live?
The release decision should rest with named authorities who understand both the technical exposure and business consequences.
A practical model separates three outcomes:
Go: Required controls have passed, supporting evidence is available and designated business and technical approvers have authorised release.
Conditional go: Residual risks are documented, proportionate and formally accepted by authorised stakeholders, with safeguards, owners and remediation deadlines.
No-go: Material security weaknesses, failed critical-process tests, unsupported dependencies or missing recovery and support arrangements make production use unacceptable.
Critical risks should not be bypassed simply to meet a deployment date.
Production approval must account for ongoing cost
Licensing, monitoring, support capacity and future changes all affect the cost of operating a Power App. Reviewing these before release reduces the likelihood of unexpected expenditure or an application becoming difficult to maintain.
GO ERP’s discovery, solution design and Power Platform support capabilities can help organisations translate these requirements into practical release controls.
The objective is a decision supported by evidence, with clear accountability for what happens after approval.
An approvals application provides a useful way to test whether those controls work beyond the checklist.
Prove production readiness where business workflows are most likely to fail
A production-readiness checklist becomes valuable when it exposes failures that ordinary testing overlooks.
Consider a purchasing approvals app built with Power Apps and Power Automate, connected to Dynamics 365 Business Central.
Employees submit purchase requests, managers approve expenditure within delegated limits, and approved transactions are passed to the ERP system.
The process appears straightforward. Its reliability depends on how the application handles exceptions.
What happens when an approval cannot be completed?
Before wider deployment, the business should test scenarios that could interrupt purchasing or compromise transaction accuracy.
Consider five situations:
- Duplicate requests: Can the application identify repeated submissions before creating duplicate purchasing transactions?
- Unavailable approvers: Does delegation work correctly when the authorised manager is absent?
- Overdue or rejected requests: Can employees identify the request’s status and take the appropriate next action?
- Failed automation: Are unsuccessful Power Automate runs detected, assigned for investigation and recoverable?
- ERP connection failures: Can the business reconcile requests against Business Central without losing approval history or duplicating records?
These tests should follow the complete workflow, from submission through approval, exception handling and final transaction recording.
The business process owner validates the expected outcomes. Technical owners investigate connection and automation failures. Support teams demonstrate how incidents will be identified, escalated and resolved.
A failed approval that remains invisible is a production-readiness failure, even when every normal approval succeeds.
If critical failures cannot be detected or recovered, release should be withheld until suitable controls are demonstrated.
Measure whether the application remains dependable after go-live
Production approval is the beginning of operational accountability.
Four measures provide a practical performance baseline:
| Measure | What to monitor |
| Incident frequency | Failures per reporting period, considered alongside transaction volumes. |
| Active-user adoption | Proportion of intended users completing work in the application. |
| Approval completion rate | Submitted requests reaching a valid final outcome. |
| Mean time to resolution | Average elapsed time from incident detection to resolution. |
Track overdue approvals separately to identify workflow delays that may not appear as technical incidents.
Review these measures against agreed service expectations. Recurring failures may warrant technical changes; weak adoption may indicate confusing processes or insufficient training.
Frequently asked questions about Power Apps production readiness
Do smaller Power Apps need formal governance?
Yes, proportionate to their risk. A low-impact internal utility may require fewer controls than an application handling financial authorisations.
What happens when the original app developer leaves?
Documented ownership, transferable connections, accessible technical records and support arrangements should allow the application to remain operational.
How often should production readiness be reviewed?
Review after material changes to users, permissions, integrations or business processes, alongside a risk-based operational review schedule.
Make the next release decision with evidence
Select one existing Power App and apply the Six-Gate Production Test. Identify its critical dependencies, assess the evidence available and prioritise unresolved risks.
GO ERP can support this through a focused Power Apps production-readiness assessment, combining business-process discovery, technical review and practical remediation planning.
The outcome should be straightforward: a clear understanding of what is safe to release, what needs attention and who is accountable.
Low-code creates the opportunity to build faster. Good governance makes that opportunity sustainable.
