Power Apps Fundamentals, Explained Once Properly

Most introductions to Power Apps define the terms and stop. The definitions are easy to find; the reasoning behind them is not, and the reasoning is what makes the difference between using the platform and fighting it.

What Power Apps is for

Power Apps exists to close a specific gap: applications that a business genuinely needs, that are too small or too specific to justify a development team, and that are currently being run on a spreadsheet emailed between four people.

That framing sets both the value and the boundary. It is excellent at forms over data, approvals, inspections, request tracking, and interfaces onto systems that already exist. It is a poor fit for high-volume transactional systems, anything needing guaranteed sub-second latency, complex algorithmic work, and public-facing consumer applications — the last for licensing reasons as much as technical ones.

When it is the wrong tool

Being able to say this is more useful than being able to list features. If the requirement involves millions of transactions, hard real-time constraints, or an audience so large that per-user licensing dominates the budget, the honest answer is that something else fits better. Power Pages covers external audiences; a real application platform covers the rest.

The two app types

Canvas and model-driven are not two ways to build the same thing. They start from opposite ends.

• A canvas app starts from the screen. You place controls, bind them to data, and the layout is what you designed. Any data source with a connector. Complete control over appearance.
• A model-driven app starts from the schema. You define Dataverse tables, relationships, forms and views, and the application is generated from that. Little control over appearance; a great deal given to you for nothing — responsive layout, accessibility, search, and the Dataverse security model applied automatically.

The decision rule that holds up: ask what will change most often. If it is the data model and who may see which rows, model-driven. If it is the screen, canvas.

Power Pages is the third member of the family, for sites that people outside the organisation use — where the access model is table permissions and web roles rather than internal licensing.

Power Fx is not a scripting language

This is the concept that causes the most trouble, because it looks like one.

Power Fx is declarative and works like a spreadsheet. A formula on a property describes what that property is, and it re-evaluates whenever anything it depends on changes. You do not run it; you state it.

The practical consequence: a label whose Text is Gallery1.Selected.Title updates by itself when the selection changes. Nobody wrote code to update it. A developer arriving from a procedural language will reach for a variable and an update step, and the result is code that fights the model — more state, more places for it to go stale, more to maintain.

Behaviour formulas — OnSelect, OnChange — are the exception: they run in sequence when something happens. Everything else is declarative, and treating it that way is the single biggest step from writing Power Fx badly to writing it well.

Delegation is about correctness

The most consequential concept in the platform, and the most often described wrongly.

Power Apps does not hold your data. It sends queries to the source and works with what comes back, limited to a configurable number of rows. When an operation can be expressed in the source's own query language, it is delegated: the source does the work over all the data and returns a small result.

When it cannot be delegated, Power Apps retrieves records up to the row limit and evaluates the operation over those only.

That is why delegation is a correctness issue, not a performance one. A non-delegable filter over a large table does not run slowly; it returns an answer computed over a fraction of the data. Searches miss records that exist. Totals are wrong. Nothing errors, so nobody reports a bug.

Which functions delegate depends on the connector: Dataverse supports more than SharePoint, and SharePoint more than some others. The same formula can be delegable against one source and silently wrong against another — which is why the blue underline in the formula bar deserves reading rather than dismissing.

Galleries, forms and the data they show

A gallery repeats a template over a set of records. Its Items property is the query, and it is where delegation lives or dies — filtering and sorting belong there, expressed so the source can evaluate them.

A form control binds to one record and handles create, edit and view through its mode. One form with a variable mode is the right shape; three screens for three modes is the common mistake and triples the maintenance.

Variables and collections

Three kinds of state, for three jobs:

• Global variables (Set) — one value, available across the whole app.
• Context variables (UpdateContext) — one value, scoped to a screen.
• Collections (ClearCollect, Collect) — a table held in memory.

Use as little of all three as possible. Every variable is state that can go stale and has to be kept correct by hand; a formula that derives its value cannot. The commonest sign of a canvas app written procedurally is a long OnStart setting twenty variables that formulas could have derived.

Collections earn their place for data read many times in a session, for building a working set before a bulk operation, and for limited offline scenarios via SaveData. They are the wrong tool for large data, and they do not know when the source changed.

Patch or SubmitForm

SubmitForm submits a form control: it handles validation, required fields and error display for you, and it is the right choice when a form is what the user is filling in.

Patch writes specified columns to a specified record, with no form involved. It is the right choice for updating a field from a button, creating a record from values gathered across a screen, or writing to a table the user is not editing directly. It gives you control and hands you the validation and error handling in return.

Common mistakes

• Treating a delegation warning as a performance note. It is telling you the results will be wrong.
• Writing Power Fx procedurally. Variables where a formula would derive the value.
• Doing everything in OnStart. Directly proportional to how long the app takes to open.
• Filtering in the app rather than at the source. Slow, and wrong past the row limit.
• Three screens for create, edit and view. They drift apart within a month.
• Using the app to enforce access. Hiding a control is not a permission.
• ForAll with Patch for bulk work. One request per record, no transaction, unknown state on failure.

Troubleshooting the classics

Symptom	Usual cause
Search finds records that exist but misses others	Non-delegable filter; only the first page was searched
App slow to open	Too much in OnStart; load on demand instead
Data shown is out of date	Reading a collection that was populated earlier in the session
Save fails with no message	No error handling around Patch; check with IfError and Errors
Works for the maker, not for users	Data source permissions, or a connection authenticating as the maker
Form clears when navigating away	Control state is not persistent; hold in-progress values in a variable

Frequently asked questions

Do I need to be a developer?

No, and the platform is designed so you do not. Understanding data modelling, delegation and where security is enforced matters far more than a programming background.

What is the row limit, and should I raise it?

It is configurable within a maximum, and raising it treats the symptom rather than the cause. A delegable query returns the right answer regardless of the limit; a non-delegable one is wrong at any limit, just less obviously.

Can a canvas app work offline?

To a limited extent, using local collections persisted on the device, with size constraints and conflict resolution you own. Verify what the current platform supports before promising it to anyone.

Where does an app's data actually live?

Wherever the connector points. Power Apps holds no data of its own — which is the fact that explains delegation, permissions and performance all at once.

The three ideas that matter

If only three things survive from all of this: Power Fx is declarative, delegation is about correctness, and security is enforced by the data source rather than by the app. Almost every serious Power Apps mistake is a violation of one of those three.