Power Apps Discovery: What to Define Before Scoping a Build

Power Apps Modernization Discovery: What to Define Before You Scope a Business Application

By Michael Branson

Quick answer. Before anyone scopes a business application on the Power Platform, six definitions have to be settled. A definition left open in discovery does not disappear; the build settles it by assumption, and that assumption is what scope creep is made of.

The request arrives already sounding reasonable. Replace the spreadsheet the operations team runs on. Rebuild the Access database nobody can patch. Put the paper form into an app. Then the person who has to price it asks what the app has to do, and the room answers four different ways, none of them written anywhere.

That gap is the whole subject of this page. Scoping a Power Platform build is arithmetic on inputs, and discovery is where those inputs come from. When the inputs are missing, the estimate is a guess wearing a number, and every correction to it later gets called scope creep by whoever is paying for it.

What This Page Decides, and What It Hands Off

This page decides one thing: what has to be defined about a business application before its Power Platform scope can be written. Six definitions, what each one produces, and where the evidence for each one comes from.

Read this page if your destination is a Power Platform build. If the destination is a custom rebuild instead, meaning a bespoke application and not Power Apps, Power Automate and Dataverse, the discovery questions change shape and the companion guide is Enterprise Application Discovery Before a Rebuild: What Has to Be True Before You Scope the Work?. That guide covers the rebuild side and this one covers the Power Platform side; neither restates the other.

If the destination is still open, the choice comes first. Whether the workload belongs on Power Apps is a separate decision, worked through in Power Apps vs. Custom .NET: Decision Guide. Take that decision first, then come back, because what follows assumes the answer is Power Platform.

Four more hand-offs, on purpose. Which app model to build, canvas or model-driven, is an architectural decision handed off in full, and it is treated in Canvas vs Model Driven Apps in Regulated Microsoft Environments. Which data store should hold the data, once the data is understood, is a comparison this page hands off rather than makes, and it is linked where the data section reaches it. Which license each population needs, and where the break-even between plans sits, is arithmetic done elsewhere, linked where the licensing section reaches it. And where the app ends and Azure begins, once the solution has a shape, is the subject of Power Apps and Azure: The Hybrid Architecture Boundary. This page states what discovery has to establish so that each of those decisions becomes answerable, and stops there.

Why “We Know What We Need” Is Not a Scope

Everyone involved knows something. The difficulty is that no one person holds all of it, and the parts that stay unheld are the parts that cost money later.

The requirements nobody wrote down. The person who runs the process knows the exceptions: the approval that gets skipped when the requester is a director, the two customers whose invoices are handled differently, the month-end step that exists because a system upstream sends a file late. None of that is in a requirements document, because it never gets treated as one. It is just how the work goes.

An old system that lives as oral tradition. When the current tool is a spreadsheet or an aging database, its behaviour is documented in the heads of the people who use it, plus whatever the formulas do. Asking what the old system does produces a description of what it is supposed to do. Reading its actual contents produces something different, and the difference is scope.

The estimate that outran its inputs. A number given before the process is understood is an estimate of a described application, not of the one that has to exist. When the two diverge, the divergence is real work that was always going to be needed, and it arrives in the form of a change request.

Discovery prevents scope creep in one specific way, and it is worth stating narrowly: it moves the moment of discovery earlier, when a finding costs a conversation, instead of later, when the same finding costs a rebuild of something already built. It does not make the work smaller. It makes the work known before somebody commits to a date.

The Six Definitions a Power Apps Scope Rests On

The deliverable people expect from a discovery is a document. What a scope actually needs is six definitions, in this order: Process truth, Data truth, Dataverse fit, Delegation exposure, License entitlement, and Ownership. Each one settles something specific, and each one has a surface where its evidence can be read, because a definition nobody can show evidence for is an opinion the scope is resting on.

Definition	What it settles	Where the evidence is produced
Process truth	The steps as performed, including the exceptions, the hand-offs, and who decides what at each step	A walkthrough with the people who run the process, recorded against the artifacts they actually touch: the current spreadsheet or database file, the email folder the requests arrive in, and the shared inbox or SharePoint list where work queues today, with the queue and its history taken from that inbox or list’s own export and not from memory
Data truth	What records exist, what their fields mean, how many rows there are, where they live now, and which of them are wrong	An export of the current store, read directly: the Excel workbook, the Access tables, or the SharePoint list exported to a file, with row counts and duplicate counts taken from that export
Dataverse fit	Whether Dataverse should hold this data model, or whether it stays where it is and the app reaches it through a connector	The table and column inventory from the Data truth export, checked against what Dataverse tables and relationships can express, and against the environment list in the Power Platform admin center, which shows which environments already have a Dataverse database
Delegation exposure	Which queries the app will have to run over how many rows, and which of them the data source can execute on the server	The row counts from the Data truth export, read against what the process has to query, plus, once a formula exists to test, the delegation warnings Power Fx marks in the maker portal formula bar when a formula cannot be delegated over a data source that holds more than the row limit
License entitlement	Which populations use the app, what each one has to do in it, and whether the connectors those actions require sit inside the plan those users already hold	The user list per population from the Microsoft 365 admin center, read against the connector list the app design implies, and the Power Automate and Power Apps license report in the Power Platform admin center for what is assigned today
Ownership	Who owns the app, who owns the data, who approves changes, and which environment production lives in	The environment list and its assigned roles in the Power Platform admin center, read against the names your organization has actually agreed, and, where an application already exists, its owner record in the same admin center

The six are worked in the order just given; when two of them disagree about the same fact, precedence is settled here rather than in an argument later. Data truth outranks Process truth: when the walkthrough says one thing and the export says another, the export is what the system actually holds and the walkthrough is what the person running the process believes it holds, and the difference is itself a finding to record, not a discrepancy to resolve quietly. Delegation exposure outranks Dataverse fit: a data model that suits Dataverse but leaves the app’s main query nondelegable over more rows than the limit has to be resolved at the query design before the store is chosen, not after. License entitlement is a constraint rather than a rank: a design that needs a premium connector for a population holding only a seeded plan is a budget decision, and it belongs in the scope. And Ownership decides no part of the data model, which is exactly why it goes last and gets named anyway: an application with no named owner is a support problem the scope did not price.

Working out which of the six is thinnest, and what it would take to close it, is the conversation this table starts. An hour spent walking this table against one real application shows where the evidence is missing before anyone is asked to commit to a number.

Process Truth: The Process Is the Spec

The sentence people say is “the process is the spec”, and it is right. It is also why the spec is missing. A process running on people and spreadsheets is not written down anywhere in the form a builder needs.

Documenting a process before building an app on it is a walkthrough, not a questionnaire. Sit with the person who does the work while they do it, on a real item, and record what they touch and what they decide. Three things come out of that walkthrough, and a questionnaire does not reach them.

The exceptions, which carry more of the logic than the main path. The main path is short, and people describe it the same way. The variations are where the effort sits: the request type that skips a step, the approval that changes hands above a threshold, the correction path when something arrives wrong. Each one is a branch somebody has to build, and each one is easy to miss until a real item goes through.

Decisions, and who makes them. At each step, the person holding the item either passes it along or judges it. Whether that judgment is a rule the app can hold, or a human call the app should route to a person, is a question the scope has to answer for each decision it names. Record the decision and its basis; decide later whether it becomes logic.

The hand-offs, which are where the data changes hands. Work leaving one team and arriving at another changes format on the way. That transformation is either a step in the app, an integration, or a manual action the app leaves room for.

Write the result as a numbered sequence with the exceptions attached to the steps they branch from, and have the person who performed the walkthrough read it back and correct it. A process description nobody has corrected is a draft of what somebody remembers.

In one manufacturing enterprise’s proposal operation, the delivered Power Apps solution had to carry approval processes and workflows, milestone date tracking, and planned-versus-actual reporting, because those were already the shape of the work before any application existed. That is what “the process is the spec” means in practice: the app did not introduce the complexity, it inherited it, and the question is whether it was written down before or after the number was quoted.

Data Truth and Dataverse Fit: What the Old System Actually Holds

Discovery on the data is a reading exercise. Get the export and open it.

Count the rows. The row count is the number people approximate in a hallway, and it is the input that decides several later questions, including the delegation section below. Take it from the export.

Read the columns for meaning. A column called Status with, say, eleven distinct values, four of which are spelling variants, describes a workflow nobody has ever specified. A date column holding text is a validation rule waiting to be written. A column that means one thing for older rows and another for newer ones is a migration decision.

Find the duplicates and the orphans. Records that exist twice, and records pointing at a parent that is gone, are a common reason a migration takes longer than a build. They also carry a decision that belongs to the business and not to the builder: what happens to a bad record is a policy, not a technique.

Once the data is understood, the fit question becomes answerable. What is Microsoft Dataverse? describes what Dataverse is offering to hold: it lets you securely store and manage data that’s used by business applications, with data stored within a set of tables, where a table is a set of rows and columns and each column is designed to store a certain type of data, and you can also create custom tables specific to your organization. Data types and relationships are used directly within Power Apps: a relational shape expressed in Dataverse is a shape the app layer reads directly. Role-based security allows you to control access to tables for different users within your organization, which puts table-level access in the platform rather than in the app.

Read those two properties as the fit test. Where the data is relational, where relationships between records carry meaning, and where different users should see different tables, the model has somewhere obvious to live. Where the store is already a governed relational database that other systems read from, the question stops being fit and becomes migration, and that is settled by Microsoft Dataverse vs SQL Server: Best Choice for Enterprise Architects on the strength of the table and column inventory this page produces.

One environment fact belongs in the same conversation, because it constrains where a Dataverse database can be created. The Power Platform environments overview states that a Power Platform environment is a space to store, manage, and share your organization’s business data, apps, chatbots, and flows, and that it also serves as a container to separate apps that might have different roles, security requirements, or target audiences. The sentence that matters most, though, is the next one: every environment can have zero or one Microsoft Dataverse database, and whether you can create a database for your environment depends on the license you purchase for Power Apps and your permissions within that environment. Reading the environment list shows which of those already applies, before anyone commits to an answer: whether the target environment already holds a database, and whether the license in hand allows creating one. That makes “we will use Dataverse” a claim about environments and licenses, not merely about tables, one that is read off that list rather than assumed.

Delegation Exposure: The Constraint That Arrives After the Demo

Delegation is one place a Power Apps scope turns out to have been wrong, and the reason it goes unnoticed is that the failure is quiet. Microsoft’s Query limitations: Delegation and query limits is direct about the mechanism.

What delegation is. The data source can run part of a query and not the rest. Microsoft draws the line in two clauses: a query is nondelegable if it uses a feature the data source doesn’t support, and if any part of a query expression is nondelegable, Power Apps doesn’t delegate any part of the query. That last clause is the one that surprises people: it is the whole expression, not the unsupported fragment.

Where the app lands when a query is not delegated. The fallback Microsoft documents is a truncation and not an error: when a query is nondelegable, Power Apps gets the first 500 records from the data source and then runs the actions in the query, and you can increase this limit to 2,000 records. The default number of records is 500, and you can change this number for your app by changing the Data row limit setting from 1 to 2,000. So the ceiling moves; it does not go away.

Why this is a discovery question and not a build detail. Microsoft’s own warning is that if you’re not careful, a user might think a partial answer is the complete answer, and it states the consequence plainly: you get incorrect results. A screen that has been populated looks no different from one that is complete, and any count taken from it counts only the records the app received. Under the default row limit, none of this bites: with fewer than 500 records you can use any data source and formula, because the app processes data locally if the formula isn’t delegated. Above it, the app’s answers are right only if its data source can execute the query the app runs.

The evidence surface is inside the maker portal: if the data in your data source exceeds 500 records and a function isn’t delegated, Power Fx marks the formula with a blue underline, and Microsoft’s advice is to pay attention to the delegation warnings that show where delegation isn’t possible. That is a build-time signal, though, which is late for a scope. At discovery the substitute is the row count from the data export, held against the queries the process requires. When the process needs a filtered view a data source cannot execute over a table that will hold more rows than the limit, the scope has to name how that view is produced, and that is a design question with a cost attached.

Being specific about this before an estimate is written is what keeps it out of the change-request pile later. Delegation is also the question on this page that most often needs a second reading, because the answer comes from holding the row counts, the required queries and the data source’s delegable functions together rather than from any one of them alone. With the export and the process notes in hand, that reading is a short working session rather than a project.

License Entitlement and Ownership: The Two Definitions Nobody Is Assigned

These two are last because they are settled by the organization rather than by the data, and when they get left to the end of a project they become blockers.

License entitlement starts from populations, not from a plan name. List who uses the app and what each group has to do in it: the people who submit, the people who approve, the people who administer, and anyone outside the organization. Then read the design against what those users already hold. The Licensing overview for Microsoft Power Platform sets out the boundary that matters at discovery time: some Microsoft 365 licenses include limited Power Apps and Power Automate use rights, and these use rights are intended for scenarios that use Microsoft 365 data and standard connectors. They don’t provide the same rights as standalone premium licenses. The same page closes the door people reach for: some Microsoft 365 applications also include limited Dataverse use rights for data and functionality required by those applications, and these rights don’t entitle users to run standalone custom apps, premium flows, or Copilot Studio agents.

The discovery consequence is narrow and worth writing down as a sentence in the scope: a design that reaches an on-premises database or a premium connector has made a licensing decision on behalf of the populations whose actions go through it. Which plan then follows, and where the break-even between plans sits for a given population size, is arithmetic done in Power Apps Premium vs Per App; what discovery owes is the population list and the connector list, so that arithmetic has inputs. What is assigned today is readable from the Power Automate and Power Apps license report the same documentation names, and the population list from the Microsoft 365 admin center.

Ownership is four names, and a project that cannot produce them has just found its first scope item. Who owns the application. Who owns the data in it, which is a different person when the data belongs to a business function and the app belongs to IT. Who approves a change. And an environment administrator, named for whichever environment production lives in.

The platform records some of this and decides none of it. Microsoft is explicit that users or groups assigned to environment roles aren’t automatically given access to the environment’s database, if it exists, and must be given access separately, so an ownership model that names an environment admin has not thereby named a data owner. And the default environment, which every tenant gets automatically, doesn’t provide any backup guarantees and shouldn’t be used for production workloads, which is why “where does it run” has a wrong answer.

Naming these four the first time is short work that stalls for long reasons: the platform’s constraints and the organization’s own approval rules bind the same scope, and only one of the two has an admin center to read it from. i3solutions has been a Microsoft partner since 1997.

What Kills Power Apps Projects in the First Ninety Days

The early failures are recognisable, and each one traces back to a definition the discovery did not close. They are worth naming as symptoms, because a project already inside one of them can read backwards to the cause.

The demo that was built on a sample of, say, twenty rows. A working prototype against a sample dataset proves the screens, and above the row limit it proves nothing about the query behaviour, for the reason the delegation section gives. When the real data arrives and totals stop matching, the fix is a design change to something already accepted.

An approval nobody described. The build implements the main path, and the first real week produces the exception the process always had: a branch, a notification, a second approver, none of it scoped. It surfaces as a change request only because Process truth arrived late, with nothing in the scope to compare it against.

The licence discovered at rollout. The app connects to an on-premises system through a premium connector, and the population that has to use it holds a plan that does not include one. The technical work is finished and the project stops anyway, because the remaining question is a budget question nobody was asked.

An owner who was never named. Go-live happens and the builder moves on, leaving the first change request with no one to accept it. The application keeps running regardless, which is what makes this failure slow: it ends up business-critical and unmaintained.

The environment that was the default one. Production runs where the prototype was built, because nobody decided otherwise, and the property Microsoft warns about, no backup guarantee on the default environment, is a property nobody chose.

Read that list as a pre-mortem, not a warning: each symptom names the definition to close, and the framework table says where the evidence for it comes from. A programme already past this point, with several apps in it and a governance problem rather than a scope problem, is a different situation entirely, worked through in Why Power Platform Initiatives Fail in Large Organizations and How to Fix Them.

When This Is Not the Discovery You Need

Three readers arrive here and belong somewhere else first: the custom-rebuild reader, the reader who has not yet chosen a platform, and the reader scoping a portfolio rather than one application.

Where the destination is a custom rebuild, not a Power Platform build, the discovery questions belong to the companion guide, Enterprise Application Discovery Before a Rebuild: What Has to Be True Before You Scope the Work?, which covers that side.

When the destination is undecided, that choice comes first, not this page: work through the decision guide above, then come back once Power Platform is the answer.

And where the question is not one application but a portfolio, the first work is choosing which candidate comes first. That choice belongs to the Excel modernization guide in Related Reading; come back to this page for whichever candidate comes out first.

What is left is the case this page was written for: one application, a real process behind it, and somebody about to be asked for a number. Bring the current system’s export, the people who run the process, and the list of who has to use the result. A senior architect works those materials into the six definitions with you, so the number you eventually give is one the build can keep. Talk to a senior Power Platform architect

Frequently Asked Questions

What should we define before scoping a Power Apps build?

Before scoping a Power Apps build, six definitions have to be settled, in this order: Process truth, Data truth, Dataverse fit, Delegation exposure, License entitlement, and Ownership. Process truth is the steps as performed, including the exceptions, the hand-offs, and who decides what at each step, recorded from a walkthrough on a real item, not from a questionnaire. Data truth is what records exist, what the fields mean, how many rows there are, where they live now and which records are wrong, taken from an export of the current store. Dataverse fit is whether the data model those records describe should move into Dataverse or stay where it is and be reached through a connector. Delegation exposure is which queries the app has to run over how many rows, and which of those the data source can execute on the server. License entitlement is which populations use the app, what each has to do, and whether the connectors those actions need sit inside the plan those users already hold. Ownership is who owns the app, who owns the data, who approves changes, and which environment production runs in. Each one has a surface that produces its evidence, so none of them rests on recollection.

What discovery prevents Power Apps scope creep?

The discovery that ends in artifacts, not in agreement. Scope creep is not usually new work appearing; it is work that was always required becoming visible after somebody committed to a number. Three artifacts do the work of prevention. A process walkthrough that follows a real item end to end, with the exceptions attached to the steps they branch from, so the branches are counted before they are quoted. The current store exported to a file, with the row counts and duplicate counts read from it, so the migration is sized, not assumed. And a population-and-connector list, so a licensing consequence lands as a scope line and not as a rollout surprise. Discovery does not make the work smaller. It moves the moment a finding appears from build time to definition time, which is where a finding costs a conversation.

How do we document a process before building an app on it?

Walk it, do not survey it. Sit with the person who performs the work and watch a real item go through, recording what they touch and what they decide at each step. Capture three things a questionnaire will miss: the exceptions, which carry more of the logic than the main path and which nobody thinks to report because they are just how the work goes; the decisions, with who makes each one and on what basis, so that a judgment the app should route rather than replace is identified as such; and the hand-offs between teams, where data changes format and either an integration or a manual step has to exist. Write the result as a numbered sequence with each exception attached to the step it branches from, then have the person you watched read it back and correct it. A process description nobody has corrected is a record of what one person remembers.

What kills Power Apps projects in the first ninety days?

Five failures, each traceable to a definition left open. A demo built on a small sample, which proves the screens and not the query behaviour over a full-size table, so totals stop matching when real data arrives. An exception the process always had arrives in the first real week. It becomes a change request because the scope had nothing to compare it against. A licensing consequence found at rollout, where the design reaches an on-premises system or a premium connector and the population that has to use it holds a plan without one. An application that goes live with no named owner keeps running anyway, and unmaintained is what it becomes. And a production workload sitting in the tenant’s default environment, which Microsoft’s environments documentation says has no backup guarantee. Read the list as a pre-mortem: each symptom names the definition that was left open, whether that is Process truth, Delegation exposure, License entitlement or Ownership.

What is delegation, and why does it belong in discovery?

Delegation is whether the data source performs the query work or the app does. Microsoft’s documentation puts it in two parts: a query is nondelegable if it uses a feature the data source doesn’t support, and if any part of a query expression is nondelegable, Power Apps doesn’t delegate any part of the query. When a query is nondelegable, Power Apps gets the first 500 records from the data source and then runs the actions in the query, and that limit can be increased to 2,000 records by changing the Data row limit setting from 1 to 2,000. It belongs in discovery because the failure is quiet: Microsoft warns that if you’re not careful, a user might think a partial answer is the complete answer, and states the consequence plainly: you get incorrect results. Under the default row limit it does not bite, since with fewer than 500 records any data source and formula can be used, because the app processes data locally. The discovery input is therefore the row count from the data export, held against the queries the process requires.

Who owns a Power Apps application after go-live?

Four roles, each held by a named person before the scope is signed, not after the build. An application owner, who answers for the app itself and its releases. A data owner, who answers for the records and for what happens to bad ones, and who is often in the business function rather than in IT. A change approver, who decides what gets built next. And an environment administrator for wherever production runs. The platform records part of the four and decides none of them. Per the environments documentation, users or groups assigned to environment roles aren’t automatically given access to the environment’s database, if it exists, and must be given access separately, so naming an environment administrator has not thereby named a data owner. And the default environment doesn’t provide any backup guarantees and shouldn’t be used for production workloads, which makes the environment question part of the ownership answer.