Approval without scope is approval of an assumption
A Power Platform project is ready for credible approval only when the business process, users, data sources, architecture, licensing assumptions and post-go-live responsibilities have been defined together. Licensing is not a separate purchasing task. It follows from how the solution will be used, connected, governed and supported.
That distinction matters because a Power Apps idea can appear inexpensive while the harder questions remain unanswered.
A request may begin as “a simple app for the operations team”. Once examined properly, it may need access for several departments, data from Dynamics 365 or another ERP, approval workflows, audit history, mobile use, security controls, training and service-desk support.
The app has not suddenly become expensive. The original estimate was based on an incomplete picture.
Microsoft’s own Power Platform guidance treats discovery, security, governance, operational management and continuous improvement as connected parts of adoption, rather than optional work added after the build.
Use the SCOPE Approval Gate
Before requesting a firm budget, test the project against five questions:
S — Solve: What business problem must the app remove, and what measurable operating change should result?
C — Consumers: Who will use it, how often, in which roles and across how many apps or processes?
O — Operating model: Who owns the process, supports users, approves changes and maintains the solution after launch?
P — Platform design: Which data sources, connectors, environments, integrations and security controls are required?
E — Economics: What will discovery, delivery, licensing, adoption, support and future change cost?
This is more than a scoping checklist. It is a decision-control layer for IT, finance and transformation leaders.
Weak inputs create hidden approval risk
| Weak input | Hidden assumption | Likely business risk |
| “Around 20 users” | Every user needs the same access | Licence estimates may be too high or too low |
| “It connects to our data” | The source and connector are straightforward | Integration effort appears late |
| “The team will support it” | Ownership and support capacity already exist | The app becomes dependent on one maker |
| “Training will be minimal” | The new process matches current working habits | Adoption slows and expected value is delayed |
| “It is only a small app” | Business criticality will remain low | Governance and testing are underfunded |
Low-code can reduce some development effort. It does not remove the need for clear process design, accountable ownership or production-grade controls.
The safest approval conversation starts by defining what the business is actually committing to operate, not merely what it hopes to build.
Power Apps licensing follows real usage
Power Apps licensing should be reviewed during solution design, not after the project has been priced.
The correct licensing route depends on how people will use the solution, which data it connects to, how many apps are involved and whether the design relies on Dataverse, premium connectors, custom connectors or wider Power Platform services. A user count on its own is not enough.
Start with the user model
Before comparing licence options, divide the audience into practical groups:
- Makers who create or maintain the solution
- Regular users who rely on it as part of daily work
- Occasional users who access it only at certain points
- Users who need one app rather than several
- Internal employees, contractors or external participants
- People whose existing Microsoft licences may provide limited use rights
This exercise exposes a common costing error: assuming everyone needs identical access.
A team of 200 people may include 20 daily users, 80 weekly users and 100 employees who only approve an exception once a month. Treating all 200 as one licensing group may lead to unnecessary spend. Treating them all as occasional users may understate the access required for compliant, dependable operation.
Use the licensing decision test
| Usage pattern | Design dependency | Licensing question | Approval risk |
| One departmental app | Standard data sources | Are existing rights sufficient? | Unnecessary licence spend |
| Several production apps | Shared data and workflows | Is broader app access required? | Under-costed expansion |
| Dataverse-based solution | Structured business data | What Dataverse rights are needed? | Late architecture change |
| Premium or custom connector | ERP, SQL or third-party data | Does every user require premium access? | Cost discovered after build |
| Irregular use | Variable demand | Would pay-as-you-go merit review? | Paying for unused capacity |
| External participation | Separate identity and access model | How will external access be licensed and secured? | Compliance or access failure |
The table is a starting point, not a substitute for validating the current Microsoft licensing terms against the final design.
Microsoft’s own Power Apps guidance shows that environment, Dataverse and security-role requirements can affect who can create, save and share solutions. These platform choices are part of the operating design, not administrative details to resolve later.
Record the assumptions behind the estimate
A credible Power Platform cost estimate should state:
- Users: roles, numbers and access frequency
- Apps: how many each group will use
- Data: Dataverse, Microsoft 365, ERP or third-party sources
- Connections: standard, premium or custom
- Automation: flows, approvals and service dependencies
- Environments: development, test and production needs
- Evidence: the licensing source and date checked
This creates a traceable basis for approval. When scope changes, leaders can see which cost assumption has changed and why.
The aim is not to find the cheapest licence in isolation. It is to select a compliant licensing model that matches real usage without over-buying access the business does not need.
Licence price is only one line in the cost model
Power Platform total cost of ownership is the full cost of designing, building, governing, operating and improving the solution over time. It includes licences, but it also includes the work required to make the app reliable, secure, usable and supportable after go-live.
A licence-only budget creates false confidence because the wider delivery and operating costs still have to be absorbed somewhere.
Build the cost model across six layers
| Cost layer | What it includes | Why it matters |
| Discovery | Process mapping, requirements, success measures and scope control | Reduces rework and prevents approval based on vague assumptions |
| Architecture | Data model, environments, integrations, security and access design | Controls technical debt, reliability and future change cost |
| Delivery | Configuration, development, automation, testing and deployment | Converts the design into a working production solution |
| Adoption | Training, communications, role changes and user support | Protects uptake and the expected business benefit |
| Operations | Monitoring, administration, incident handling and documentation | Reduces key-person dependency and protects continuity |
| Improvement | Releases, optimisation, new requirements and capacity review | Keeps the app useful as processes and demand change |
This structure matters because each layer protects a different part of the business case.
Discovery protects the budget. Architecture protects control. Testing protects continuity. Training protects adoption. Documentation protects supportability. Ongoing management protects the solution from becoming an unmanaged dependency.
Microsoft’s own implementation guidance treats discovery, security, governance, operational excellence and continuous improvement as connected parts of Power Platform adoption. These are not optional extras added by cautious delivery teams; they are part of running the platform responsibly.
Separate known cost from uncertain cost
A credible approval pack should divide spend into three categories:
- One-off delivery cost: discovery, design, build, testing, deployment and initial training.
- Recurring cost: licences, support, administration, monitoring, capacity and planned improvement.
- Risk-dependent cost: legacy integration, poor data quality, complex security, unclear ownership or expansion beyond the original user group.
This distinction improves decision quality. Finance can see what is committed, what will continue and what still depends on unresolved assumptions.
Consider an app that replaces a manual quality process. The visible build may be modest. The real cost changes once the business requires ERP data, controlled approvals, offline use, audit history, production support and evidence for compliance reviews.
The right question is not, “How much does the app cost?”
It is, “What must be funded for this process to work reliably after launch?”
That is the point where Power Platform project cost becomes commercially useful rather than deceptively simple.
Cost is shaped before it is priced
Power Platform project cost is largely determined by design choices made during scoping. User scale, data architecture, integration depth, governance, testing and support expectations all change what must be built and maintained.
That is why a prototype, a team app and an enterprise solution should never share the same costing assumptions.
| Decision area | Prototype | Team app | Enterprise solution |
| Purpose | Test feasibility | Support a defined process | Run a business-critical process |
| Users | Small test group | One team or function | Multiple teams, sites or regions |
| Data | Sample or limited data | Controlled production data | Shared operational data |
| Integration | Minimal | Selected systems | ERP, CRM or third-party services |
| Governance | Basic controls | Defined ownership and access | Formal environment, security and release controls |
| Testing | Functional proof | User acceptance and regression testing | Broader performance, security and continuity testing |
| Support | Temporary project support | Named business and IT owners | Defined service model, monitoring and escalation |
| Licensing review | Indicative | Usage-based validation | Full architecture and entitlement review |
The lowest initial figure is not always the lowest-cost design. A cheaper data source may create duplicate records. A quick point-to-point integration may increase support effort. An informal maker-led support model may work during a trial but become a continuity risk once the app is relied on every day.
Apply a red-amber-green approval test
Use the SCOPE Approval Gate before committing the full build budget.
Green: The business problem, users, operating model, platform design and economics are evidenced. The project is ready for firm approval.
Amber: The use case is credible, but important assumptions still need structured discovery. Approve a scoping stage rather than an artificial fixed price.
Red: The process, ownership, data or user model remains unclear. A firm estimate would be guesswork.
This gives IT and finance a more honest decision. It also gives transformation leaders a controlled route forward without forcing false certainty too early.
Power Platform scoping FAQs
When should Power Apps licensing be reviewed?
Review it during solution design and again before approval. User roles, app count, data sources, connectors and access frequency can all change the licensing requirement.
What usually changes the cost of a Power Platform project?
The largest changes usually come from integration, data complexity, governance, testing, adoption, support and growth beyond the original user group.
Do Microsoft 365 licences cover every Power App?
No. Included rights are limited and depend on the services, connectors and access scenario. The final design should be checked against Microsoft’s current licensing terms.
Can a prototype move straight into production?
Only when its architecture, security, data, testing, ownership and support model meet production needs. A working prototype proves an idea; it does not automatically prove operational readiness.
A Power Platform scoping review should leave leaders with a process map, user model, licensing assumptions, architecture options, delivery responsibilities and an initial total-cost range. That is a stronger basis for approval than a licence quote or an early build estimate.
GO ERP supports this through structured discovery, solution design, licensing review, architecture, integration, governance, adoption and post-go-live support. The practical next step is a scoped readiness session that tests the SCOPE Approval Gate before the business commits to delivery.
