Power Platform architecture

Dataverse vs SharePoint lists: choosing the data layer under your Power Apps build

By Edward Pinela — Microsoft-certified consultant · September 14, 2026

Dataverse vs SharePoint lists for Power Apps is a data-layer decision, and it is the one decision on a low-code project that is genuinely expensive to reverse. Screens can be redrawn in an afternoon. Moving a live app from a list to a relational backend means rebuilding columns, lookups, permissions and every flow that touched the data. This guide covers the five things that actually decide it — relational structure, delegation, the security model, model-driven support, and what happens when the app grows — so the choice is made before the first screen is drawn rather than after the first complaint.

Start from the list, and let a requirement move you

Our default recommendation on a fixed-fee build is the SharePoint list, and we ask what forces us off it. That is not a cost dodge: the list is included in the Microsoft 365 subscription the client already pays for, every user can already open it, and a large share of the processes people want an app for are one table of records with a status column and an approval. Reaching for a relational platform because the project feels important is how a two-week build becomes a two-month one.

The honest reason to choose Dataverse is a specific requirement you can name in a sentence — “field engineers must not see each other’s jobs”, “salary has to be invisible to the people who edit the rest of the record”, “this is five related tables, not one”. If nobody can produce that sentence, the list is the right answer this quarter. The sections below are the requirements that, in our experience, genuinely produce it.

Every Microsoft behaviour described on this page was checked against Microsoft’s published documentation on 14 September 2026, and each claim links to the page it came from.

Relational data: lookups are not relationships

A SharePoint list will hold a lookup column pointing at another list, and for one parent with one child that is usually enough. What it does not give you is a modelled relationship: cascade behaviour when a parent is deleted, referential integrity enforced at the data layer, rollup and calculated columns maintained by the platform, or alternate keys that stop a duplicate being created in the first place. In Dataverse those are properties of the table, so every app, flow and report that touches the data inherits them.

That distinction is invisible on day one and expensive in year two. When three or four lists depend on each other, the integrity logic has to live somewhere, and on a list-backed app it lives in Power Fx and in flows — written once by whoever built the app, and re-derived by whoever maintains it next. A process with a genuine entity model behind it (jobs, sites, assets, inspections, parts) is the clearest signal that the data layer deserves its own design, which is how we scope Microsoft Dataverse consulting services: the model, the relationships, the security roles and the solution pipeline, delivered as a thing the apps are then built on top of.

Delegation: the limit that makes an app return the wrong answer

Delegation is the single most useful concept to understand before choosing a backend, because it is the one that produces silently incorrect results rather than obvious errors. Power Apps tries to translate a Power Fx query into something the data source can run. When it cannot, it pulls rows to the device and filters locally — and Microsoft’s guide to delegation in a canvas app (opens in new tab) is explicit that only the first 500 records come down by default, adjustable up to 2,000. A search for a record at position 3,000 does not fail. It returns nothing, and the user believes the record is gone.

Both backends delegate; they delegate different things. Microsoft publishes a per-connector table, and the delegable functions and operations for SharePoint (opens in new tab) have real gaps worth knowing: greater-than and less-than comparisons do not delegate on text or yes/no columns, IsBlank does not delegate, Not does not delegate, sorting does not delegate on complex column types such as choice, lookup or person, only Email and DisplayName are delegable within a person column, and a list’s ID column supports only equality. Dataverse’s equivalent table is broader, which is why a query pattern that quietly caps out on a list can run untouched against a table.

The practical reading: if the app will ever hold more than a couple of thousand rows and users will search or filter them in ways that go beyond simple equality on text, verify the specific queries against the delegation tables before committing to the list. Volume alone is not the trigger; volume combined with a non-delegable query is.

The security model is where the two platforms diverge most

SharePoint secures items. You can break inheritance on a list item, and for a handful of exceptions that works. It stops being a strategy at scale: Microsoft’s published SharePoint limits (opens in new tab) put the supported number of unique permission scopes in a list at 50,000 while recommending a general limit of 5,000, and note that inheritance cannot be broken or re-inherited on a list, library or folder holding more than 100,000 items. There is also no column-level permission: if a person can open the item, they can read every column on it.

Dataverse was built for exactly this problem. Microsoft’s security concepts in Microsoft Dataverse (opens in new tab) describe role-based security composed with business units, owning and access teams, record sharing for exceptions, and column-level security applied through column security profiles so a salary or a diagnosis can be hidden from users who can otherwise see the record. Two cautions from the same page are worth carrying into design: privileges are cumulative, with the broadest access winning, and the whole model exists only where there is a Dataverse database in the environment.

So the test is not “is this data sensitive” — a private SharePoint site handles sensitive data perfectly well. The test is whether different people need different rows or different columns of the same table. If yes, that is a Dataverse requirement. If the answer is “everyone in the department sees everything”, a list in a site with a sensible membership model is the simpler and cheaper control, and it belongs in the same information architecture as the rest of your content — which is how we approach SharePoint consulting engagements.

Model-driven apps exist only on Dataverse

If the requirement includes a model-driven app, the decision is already made. Microsoft’s model-driven apps overview (opens in new tab) states that without a data model housed within Dataverse you cannot create a model-driven app, and its comparison table lists the model-driven data platform as Dataverse only, against “Dataverse + many others using connectors” for canvas apps.

That is a smaller constraint than it sounds for most small-business projects. Model-driven apps earn their keep on record-dense, process-heavy work where users move between related records all day — case management, member relationships, a structured sales process. The counterpart is that you give up layout control; the interface is generated from the tables, forms and views you configure. A canvas app on a SharePoint list, built to fit one job on one screen, is what most teams actually pictured when they asked for an app. Which of the two shapes your process deserves is a separate decision from this page’s, and we work it through in canvas apps vs model-driven apps — including the hybrid, where a model-driven core carries a canvas-style page for the part that has to be simple.

The comparison, row by row

The table below is the checklist we walk through in scoping. It is deliberately about capability rather than price: the licence consequence is real but it is one line, not the frame.

One sentence on the money, because it belongs to a different page: a Dataverse-backed app needs standalone Power Apps licensing for each user, where a list-backed app on standard connectors runs on rights Microsoft describes as already seeded in many Microsoft 365 licences for Power Apps (opens in new tab) — the plans, the break-even and the add-ons are covered in Power Apps licensing for small business, and the build-side scope drivers in what a Power App costs to build.

Reading your own requirements

Most scoping calls resolve in about ten minutes once the requirement is stated as a sentence rather than a preference. These are the signals that decide it in practice.

What happens when the list is no longer enough

Outgrowing a list is a normal outcome, not a failed decision, and it is worth knowing what the move costs before you make the first choice. The app’s screens and most of its Power Fx survive. What does not survive is the data layer itself: column types have to be re-declared, lookups become real relationships, per-item permissions become security roles, attachments need a home, and every Power Automate flow bound to the list has to be repointed and retested. Plan it as a small project with its own scope, not as a setting. And if the move is not a foregone conclusion because a SQL database is also on the table, our guide to Dataverse vs Azure SQL for Power Apps covers that next decision: what the Dataverse business layer supplies and what a SQL backend asks your team to own.

Two habits make that migration cheap. Design the list as though it were already a table — sensible column names, one fact per column, no free-text where a choice belongs, and no business logic hidden in a view. And keep the app’s data access in a small number of named queries rather than scattered through every screen, so repointing is a contained edit. Teams that do this move backends in days. Teams that do not usually rebuild.

Once several apps and flows exist across the tenant, the next question shifts from architecture to administration — which environment each app belongs in, which connectors makers may combine, and who owns the app whose author has left. That is scoped separately as Power Platform governance consulting services, and it is usually the right purchase after the second or third app rather than before the first.

How we make the call on a fixed-fee build

On a scoped engagement the backend decision happens in the design conversation, before anyone opens a screen. We write down the entities and how they relate, the rows each role may see, the columns anyone must not see, the realistic record volume in year three, and the queries the app will actually run. If none of those force a relational platform, we build on a SharePoint list and say so in the scope, because the cheapest defensible architecture is the one the client can run without us.

Where the model is the substantial part of the work, it is designed and documented in its own right; where it is not, we do not invent it. That decision, and the reasoning behind it, is written into the scope you approve before the fee is agreed. Our fixed-fee Power Apps consulting engagements are delivered by senior US-based engineers in a typical two to four weeks, with 30 days of hypercare after go-live, and everything is built in your own tenant and stays yours. Tell us what the app needs to do and we will tell you which backend it needs — before you commit to either.