Working with Dataverse in apps

What it does

Dataverse is the native data source for Power Apps. A canvas app binds to the current environment's tables by default, so moving the solution to test or production repoints the app automatically. Model-driven apps sit directly on it. Security roles, relationships, views and business logic all come from the platform rather than from the app.

Key facts

The connection follows the environment. Move the app and it reads the new environment's data with no rebinding — which is the whole ALM story in one behaviour. Change environment lets you point at a different one deliberately.
Native Dataverse connections don't require additional user consent, so they don't appear in the connections list on the app details pane.
Delegation coverage is the broadest of any source: comparisons, And/Or/Not, Filter, First, In for both membership and substring, Lookup, Search on text, Sort, SortByColumns, StartsWith, and CountRows/CountIf.
Aggregate functions are limited to 50,000 rows and aren't supported on views. CountRows uses a cached value; CountIf( table, True ) gives a live count under 50,000 records.
Arithmetic inside a filter expression isn't delegated. Neither is Trim, TrimEnds or Len on text, casting a column with Text(), or Now() and Today() in a DateTime comparison.
The In operator is subject to Dataverse's 15-table query limit.
FirstN isn't supported for delegation, and UpdateIf/RemoveIf simulate it in 500 or 2,000 record batches.
Dataverse actions can be called directly from Power Fx by adding the Environment language object as a data source. Both bound and unbound actions, system and custom, and the old two-level call limit is gone.
Microsoft now recommends direct Power Fx action calls over routing through Power Automate for transactional reads and updates, and Studio shows a banner suggesting the switch.
Security roles in the environment control what a maker sees even when the environment appears in the list. No read privilege means no visible tables.

When to use / skip

If the client has any Power Platform licensing that includes Dataverse, this is the default and the burden of proof sits with anything else. Relational modelling, row-level security, auditing, proper delegation and environment-aware connections are all things you'd otherwise build badly by hand. Skip it only when the data genuinely belongs to another system of record and the app should be reading it live rather than copying it. "We already have the list in SharePoint" is not a reason; it's a migration task.

Configuration decisions

Views versus filters in the app. A saved view moves the definition into the platform where non-makers can change it; a Filter in the Items property keeps it under source control in the solution.
How deep relationships are traversed, given the two-lookup-level limit in query expressions and the 20-entity expand ceiling.
Whether transactional logic runs as a Dataverse action called from Power Fx, a plug-in, or a flow — and the direct action route is now the recommended one for reads and updates.
Whether counts come from cached CountRows or live CountIf, and what happens above 50,000 rows.
Which columns the app actually needs, since Explicit Column Selection only helps if the lineage survives.

Gotchas

Aggregates on views simply aren't supported, and that's easy to miss because the formula looks fine and returns something.
CountRows returning a cached number surprises people who expect it to match what the gallery just showed them.
Today() and Now() inside a Dataverse filter break delegation. Assign the value to a named formula or variable first so it's a constant by the time the query is built.
The maker's security role controls the design-time experience too. A maker with narrow privileges sees a partial table list and concludes the environment is broken.
Filtering on a related table's column doesn't delegate the way filtering on a base column does, and there's no obvious visual difference between the two formulas.

Consultant notes

The environment-aware connection is the single strongest technical argument for Dataverse over SharePoint on any project with more than one environment. Lead with it, not with the feature list.
Direct Dataverse actions from Power Fx changed the standard architecture. If a client's estate routes every write through a flow, that's now technical debt worth quantifying rather than a pattern to copy.
Get security roles designed before the app, not after. Retrofitting row-level security onto a finished canvas app means reworking every query that assumed the user could see everything.
Warn the client that Dataverse capacity is consumed by the data model, not by the app. It's an ongoing cost line and it belongs in the business case at the start.

Worth revisiting each release wave — the Dataverse delegation table and the direct-action story both keep moving.