Episode Details
Back to Episodes
SharePoint list Power Apps: fix the list mistake that breaks your app
Season 1
Published 5 months, 2 weeks ago
Description
(00:00:00) The SharePoint Dilemma
(00:01:20) The Illusion of Easy App Creation
(00:02:41) The Hidden Costs of SharePoint Lists
(00:04:21) The Delegation Disaster
(00:07:37) The Scalability Wall
(00:11:46) The Governance Gap
(00:15:53) Data Verse: The Scalable Alternative
(00:21:18) The Final Verdict and Homework
SharePoint list Power Apps: in this episode of M365.fm, Mirko Peters shows why building Power Apps directly on SharePoint lists feels great on day one and quietly destroys performance, scalability, and data integrity once real users and real data arrive. He contrasts what proper backends like Dataverse and SQL Server are designed to do—schemas, indexing, relationships, execution plans, and concurrency—with what SharePoint was actually built for: collaboration, documents, and light metadata, not production‑grade application databases. You will hear why the “Create an app” button is perfect for demos but deadly for long‑term apps, and how treating lists like tables guarantees throttling, delegation issues, and broken trust in your data.
Mirko unpacks why everyone starts with SharePoint: it’s already in Microsoft 365, feels free, and Power Apps lives right in the ribbon, giving you that instant “I built an app in 30 seconds” dopamine hit. He explains how this convenience hides the structural mismatch: list items stored as JSON blobs, views optimized for documents, and architecture that was never meant to behave like a relational engine. As record counts grow and more people use the app, you start seeing timeouts, partial results, and performance cliffs—not because Power Apps is bad, but because SharePoint is being forced into a role it was never designed to play.
The episode then dives into the delegation disaster. Mirko explains how non‑delegable functions (Search, Or, Len, text operations) push filtering to the client, so Power Apps only pulls 500–2,000 records and filters locally—silently dropping the rest. Your app still “works,” but it lies: users see incomplete data, dashboards show half the truth, and critical workers “disappear” from views when lists get big. He shows how this leads to a crisis of trust, where performance is only the symptom and the real problem is that no one can rely on the numbers anymore.
You also get a scalability playbook. Mirko outlines when SharePoint lists are perfectly fine (small tools, low‑risk tracking, collaboration helpers) and when you must start in Dataverse or SQL to avoid an expensive rebuild later. He walks through telltale red flags—growing record counts, multiple related lists, heavy lookups, reporting demands, multi‑user writes—and shows how to model data, plan migrations, and apply patterns that keep your next Power App on a real foundation instead of a glorified spreadsheet.WHAT YOU WILL LEARN
(00:01:20) The Illusion of Easy App Creation
(00:02:41) The Hidden Costs of SharePoint Lists
(00:04:21) The Delegation Disaster
(00:07:37) The Scalability Wall
(00:11:46) The Governance Gap
(00:15:53) Data Verse: The Scalable Alternative
(00:21:18) The Final Verdict and Homework
SharePoint list Power Apps: in this episode of M365.fm, Mirko Peters shows why building Power Apps directly on SharePoint lists feels great on day one and quietly destroys performance, scalability, and data integrity once real users and real data arrive. He contrasts what proper backends like Dataverse and SQL Server are designed to do—schemas, indexing, relationships, execution plans, and concurrency—with what SharePoint was actually built for: collaboration, documents, and light metadata, not production‑grade application databases. You will hear why the “Create an app” button is perfect for demos but deadly for long‑term apps, and how treating lists like tables guarantees throttling, delegation issues, and broken trust in your data.
Mirko unpacks why everyone starts with SharePoint: it’s already in Microsoft 365, feels free, and Power Apps lives right in the ribbon, giving you that instant “I built an app in 30 seconds” dopamine hit. He explains how this convenience hides the structural mismatch: list items stored as JSON blobs, views optimized for documents, and architecture that was never meant to behave like a relational engine. As record counts grow and more people use the app, you start seeing timeouts, partial results, and performance cliffs—not because Power Apps is bad, but because SharePoint is being forced into a role it was never designed to play.
The episode then dives into the delegation disaster. Mirko explains how non‑delegable functions (Search, Or, Len, text operations) push filtering to the client, so Power Apps only pulls 500–2,000 records and filters locally—silently dropping the rest. Your app still “works,” but it lies: users see incomplete data, dashboards show half the truth, and critical workers “disappear” from views when lists get big. He shows how this leads to a crisis of trust, where performance is only the symptom and the real problem is that no one can rely on the numbers anymore.
You also get a scalability playbook. Mirko outlines when SharePoint lists are perfectly fine (small tools, low‑risk tracking, collaboration helpers) and when you must start in Dataverse or SQL to avoid an expensive rebuild later. He walks through telltale red flags—growing record counts, multiple related lists, heavy lookups, reporting demands, multi‑user writes—and shows how to model data, plan migrations, and apply patterns that keep your next Power App on a real foundation instead of a glorified spreadsheet.WHAT YOU WILL LEARN
- Why SharePoint lists are collaboration storage, not real databases, and how that impacts Power Apps.
- How delegation limits, 500/2,000‑item caps, and throttling quietly turn list‑backed apps into liars.
- How JSON blob storage, weak relationships, and lookup overload create performance and dataloss risks.
- When it is safe to stay on SharePoint—and when you mus