What it does

SharePoint lists and Excel tables are both tabular sources you can bind a canvas app to with a standard connector. SharePoint delegates a useful subset of Power Fx and carries its own list thresholds; Excel is a file in cloud storage with a table in it, and it delegates nothing.

Key facts

• SharePoint delegates = across every type, comparisons on Number and DateTime, Filter, Lookup, Sort, SortByColumns and StartsWith on text. And and Or delegate; Not does not.
• SharePoint ID columns show as numbers in Power Apps but are text underneath, so only = delegates on them. Relational operators on an ID don't work.
• IsBlank( column ) doesn't delegate to SharePoint. column = Blank() does, though it treats an empty string differently.
• Complex SharePoint types — Choice, Lookup, Person, Managed Metadata and the rest — defer the delegation decision to the subfield. Only Email and DisplayName delegate on a Person column.
• SharePoint system columns generally don't delegate at all: Identifier, IsFolder, Thumbnail, Link, Name, FilenameWithExtension, Path, FullPath, ModerationStatus, ContentType, IsCheckedOut, VersionNumber and others.
• UpdateIf and RemoveIf on SharePoint simulate delegation in 500 or 2,000 record batches, pulling records down to evaluate them.
• Power Apps supports SharePoint lists but not template-based lists. If a list doesn't appear, you type its name into the custom table box.
• Excel workbooks must live in cloud storage — OneDrive, OneDrive for Business, SharePoint, Dropbox, Google Drive or Box — and the data must be formatted as a named Excel table before Power Apps can read it.
• Uploading a file through Start with data converts it into a Dataverse table rather than connecting to the file. The maximum upload size is 5 GB, the first 20 rows appear immediately and the rest load in the background.
• All SharePoint images require a separate call per image and shouldn't sit in a gallery or table. SharePoint does offer intermediate image sizes for use on a form.

When to use / skip

SharePoint is a reasonable source for a genuinely list-shaped problem: a few thousand rows, flat structure, no relational integrity requirement, and a business owner who already lives in the site. It becomes a false economy the moment you need real relationships, row-level security beyond list permissions, reliable delegation on anything other than equality, or more than one environment. Excel as a live data source is worse again — no delegation, no concurrency control, a file that someone will open and lock, and no meaningful security. If a client's app is on Excel, the question isn't how to make it work; it's how quickly you can get the data into Dataverse.

Configuration decisions

• Whether the list is the system of record or a staging area on the way to Dataverse, and saying which out loud.
• Which columns are simple types, because Choice, Lookup and Person columns constrain your delegation options and complicate every write.
• Whether images live in the list at all, given each one is a separate call.
• How the list is secured — item-level permissions, or an app that filters and relies on nobody opening the list directly.
• For Excel, whether you're connecting to the file or uploading it into a Dataverse table, because those are entirely different architectures with the same starting click.

Gotchas

• The ID column being text underneath catches everyone. Filter( List, ID > 500 ) produces no delegation warning that makes the reason obvious and silently returns local results.
• Not blocking delegation means the natural way to write an exclusion filter falls back to local processing.
• Person and Choice columns don't patch the way a simple column does, and the error messages when they're wrong are unhelpful.
• Excel files have no environment concept, so there's no clean way to point dev and production at different data. People solve this by copying the file, and then the two diverge.
• SharePoint has its own list view threshold behaviour independent of Power Apps' 500/2,000 delegation limit. Two different ceilings, two different failure modes, and clients conflate them.

Consultant notes

• Frame the SharePoint decision commercially. It's the right answer when the client has no premium licences and a genuinely small list; it's the wrong answer when someone chose it to avoid a licensing conversation they'll have to have anyway in eighteen months.
• Get a row count and a growth rate before agreeing to SharePoint. "Roughly a hundred a month" is the number that decides this, and nobody volunteers it.
• If you inherit an Excel-backed app, price the Dataverse migration as its own piece of work rather than absorbing it. It's a data migration plus an app rewrite, not a connector swap.
• Warn the client that SharePoint list permissions and app sharing are separate things. Sharing the app doesn't grant list access, and granting list access lets people bypass the app entirely.

---

Worth rechecking the SharePoint delegable operations table each release wave, and revisiting if list threshold behaviour changes.