Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. What PowerApps and SharePoint are and why they belong together. PowerApps stops at five hundred records and most beginners never notice. Your SharePoint list already holds the data your team cares about, and PowerApps is the friendly screen you put in front of it. Many Microsoft three hundred sixty five plans already cover running an app that stays on SharePoint, but once your list grows, the app can start showing you part of the truth without telling you. Two numbers decide whether you can trust what you see, and almost nobody explains them before you build. Welcome to the M365 FM podcast, where we explore the people, ideas, and technologies shaping the future of work. Start with the thing that trips people up. SharePoint and PowerApps are two different tools that happen to fit together well. SharePoint is where the data lives, and a SharePoint list is a table of rows and columns sitting inside Microsoft three. Sixty five it runs on the same engine as Microsoft lists. So a list you create in SharePoint also turns up in Microsoft lists. Nothing exotic is going on there. Picture a facilities team that keeps every broken thing in one list. Each row is a ticket and the columns hold the room. The problem and the status. That list is useful and annoying in equal measure. Scrolling a big table on a phone is miserable, and letting everyone edit it directly is worse. PowerApps is the fix for the second half of that problem. A power app is a screen you build on top of data you already have. The type you'll meet first is the canvas app, which simply means you design the screen however you want. So the app gets a search box, a form, and a few buttons, and it pulls data from the list and sends changes straight back to it. It's a front end for the list, so there's no new database to set up and no website for you to host. That pairing is popular for a boring reason. That turns out to matter a lot. The data is already there, so nobody has to migrate anything and nobody needs a new username or password either. The permissions people already have on the list carry straight over to the app. The people who built these apps are usually not developers. They're the person on the team who understands the process best, which is often the same person who has been holding the spreadsheet together with tape. You don't start from a blank page, and that's the part that surprises most people how a SharePoint list turns into a working app in minutes. Inside SharePoint, Every list offers a way to create an app from it, and PowerApps then builds the first version for you. It generates three screens, which is easier to picture as a list of your rows, a single row, and a form for adding or changing a row. Those screens come wired to your columns so the app already knows where the room number goes and where the status goes. The equipment list from before becomes an app where someone searches for a ticket, taps it to read the detail, and edits it when the situation changes. That first version appears in a couple of clicks, and it feels fast because it starts with the structure you already built in the list. Then the maker takes over and does the human part. You rename screens so they make sense. Hide the columns nobody needs. Move the important field to the top and mark the fields that should be required. This is also where you smooth out the small things, like a form that asks for a status before anyone could possibly know the status. The honest bit is that this first version is a starting point rather than a finished product. It works, and it looks like it came from a template, because it did the distance between an app that runs and an app people actually use is where most of the real effort lives. One thing worth knowing early is that the app and the list stay connected. at a column later, and the app can use it while deleting a column breaks whatever was pointing at it. We'll come back to that one because it catches almost everybody at least once. So you end up with something real in an afternoon and something good in a few weeks. The next question is what that app is doing with your data. What the app does with your data once the app exists. The interesting question is what it does and the answer is simpler than it sounds. The app reads from the list and writes back to it, so there's still only one copy of your data that matters more than it sounds like it should, because one copy means no syncing, no reconciliation, and no argument about which version is right. There's a related trick most beginners don't know about. SharePoint lets you replace the default form on a list with a PowerApps form, so you keep the list exactly where it is and still give people a much better screen for entering data. It's the same data, the same permissions, and a better front door. When someone submits a form, the app sends the filled in row back to the list and the row shows up in SharePoint. Like any other row, the manager who has been checking that list for years doesn't need to learn a new tool, and the person in the field doesn't need to open SharePoint at all. Both of them are working on the same rows. Permissions follow the list, which is the reassuring part and the limiting part at the same time. If you can't see a row in SharePoint, the app can't show it to you because the list is the security boundary and the app is not. That's a feature, and it's also the reason the app can't become a way around the rules you already have. A quick example pulls it together. An employee opens the app on a phone, types in a request, and taps submit. A new row lands in the same list. Their manager already checks with the same columns in the same place, and the manager never opened the app to see it. That's the plumbing and it's what makes everything else possible. What you actually touch as a builder comes down to three simple ideas. The three building blocks you only learn once. Everything you build sits on three ideas, and once they click, the rest is repetition. A screen is a page in your app. A control is a thing on that page, like a text box, a button, or a gallery that lists your rows. A property is a setting on a control, and that's where you tell the textbox what to show or the button what to do. The fourth idea sounds scary and isn't powerful is the language behind those settings, and it reads more like a sentence than like code to show a row status in a label, you point the label at the status column and let the app fill it in. You're not writing a program from scratch. You're telling one control where to get its value. That distinction matters because it's the difference between learning a language and learning where the settings live. Most people who get comfortable with power apps never memorize much syntax. They learn the handful of places where a formula goes, then copy, adjust, and reuse the ones that worked. I'll be straight with you about the time this takes. It's a weekend to feel comfortable, not an afternoon. If you've never built anything before, budget a couple of evenings to get the first app doing what you want and expect the second one to move three times faster. The mistakes you'll make along the way are friendly ones. A button that does nothing because it points at the wrong screen. A label showing the wrong column. A form that won't submit because a required field is empty. None of those touch your data and each one teaches you where to look next time. There's one more thing worth saying here, which is that experimenting is safe. You can build a messy app without moving a single row, and you can always start a new app from the same list with those blocks in hand. Here's what people build where this combination shines. Let's make this concrete, because the value shows up in ordinary work rather than in demos. The first pattern is tracking physical things like equipment, laptops, vehicles, and tools. You keep one list and the app gives people a search box and a form, which is exactly what a shared spreadsheet can't do well on a phone. The second is a request form. Almost every team has an inbox that has turned into a ticketing system where people email a request and someone retypes it into a spreadsheet. Point the app at a list instead, and every request becomes a row with a status and owner and a date with no retyping anywhere. The third is inspections and checklists. Someone walks a site with a phone, fills in a form, and the row is already in SharePoint by the time they're back at the office. No paper, no end of day transcription, and no lost notes. The fourth is the one that surprises people, which is an approval queue. The app collects the request and Power Automate, watches the list, and sends the notification when a row changes. Now you have the app and the automation working as a pair. And the automation side is where most teams save their first real hours. The fifth is simpler onboarding lists, task lists, and status boards all work the same way because their rows that a team updates and reads through a small app. That's what makes all five good starting points. None of them need a premium connector because everything stays on SharePoint, and that keeps the licensing question simple. We'll get to that shortly. You'll notice these share a shape. A small number of people create rows, a slightly larger number read them, and everyone wants to do it from a phone without scrolling. That shape is where this combination earns its keep, and it's also where the limits start to matter. Because the moment the data stops being simple rows, the tool stops being the right answer. The five hundred record wall and why your app lies to you. This is the section the opening promised. So let's take it slowly because it's the most useful thing a beginner can learn about PowerApps. You'd think the danger is a list getting too big. The real danger is a formula that can't be sent to SharePoint, which sounds like a technical detail until you see what it does to your app. Here's how it works. When you ask the app for data, it tries to hand the work to SharePoint because SharePoint is far better at sorting through rows than your phone is. Some instructions. It can run for you and some it can't. When it can't, the app pulls the rows down to your device and works through them there instead, and that fallback path has a limit of five hundred records. You can raise that number in the app settings up to a maximum of two thousand. Past that line, the app doesn't stop and it doesn't throw an error. It shows you an answer based on only part of your data, and it flags the problem with a delegation warning that most beginners click past without reading. Put a number on it. Say your list holds four thousand orders. Your search uses an instruction SharePoint can't run, so the app works through the first five hundred rows and reports that nothing else matches. Everything looks fine, and the app sounds sure of itself. It's also wrong, and nobody finds out until someone can't locate an order they know exists. The fixes are less dramatic than the problem filter on the columns SharePoint can handle, so the heavy lifting happens on the server. Keep the filtering in the list view where it belongs, and when a list outgrows this pattern, move the data to Dataverse, which is Microsoft's premium data platform and handles the things a list was never built to do. It's worth understanding why this failure is the one to remember. Most mistakes in an app are loud, a screen doesn't load, a button, does nothing, and you go fix it. This one is silent and silent. Mistakes are the ones that end up inside a decision somebody makes. So when you see a delegation warning, read it as the app telling you where its confidence ends, the five thousand item rule, and the rest of the honest limits. That's the first number. The second one belongs to SharePoint itself, and it's the one people mix up with. The first SharePoint has a limit called the list View threshold, and it's five thousand items. When a view or a filter has to work through more rows than that in one pass, SharePoint throws an error. Rather than slowing to a crawl, a SharePoint list can technically hold up to thirty million items, so this is a limit on how much SharePoint will process at once. Not a cap on how much you can store. The standard fix is to index the columns you filter and sort on, and to keep your views filtered so they touch fewer rows at a time. Indexing tells SharePoint where to look, which is the difference between a library with a catalog and a library where you walk every aisle. Now the licensing, because this is where beginners end up either pleasantly surprised or unpleasantly surprised. A lot of Microsoft three hundred sixty five plans already include the rights to run apps that stick to SharePoint lists and standard connectors, which covers all five patterns from earlier. The moment you reach for a premium connector or Dataverse, you need a paid PowerApps plan, and those come as a per user plan and a per app plan. The list price is set around twenty dollars per user per month, and around five dollars per app per month, and you should treat those as list prices because Microsoft changes them. One more limit isn't a number at all, and it bites more often than either of the others. Delete or rename a column in SharePoint list, and you break whatever in the app was pointing at it because the app holds onto the columns internal name rather than the label you see on screen. Rename things inside the app and leave the list alone once it's in use. Performance is the softer limit. Worth naming a list with a few thousand rows and a sensible set of indexed columns feels instant. A list with hundreds of thousands of rows filtered the wrong way will feel slow no matter how well the app is built. Because you're asking SharePoint to do something it's designed to avoid. None of this is a reason to avoid the tool. It's the reason to learn where the edges are before you commit. And knowing the edges is the difference between an app that keeps working, and one that stops being true without anyone noticing how this fits into Microsoft three hundred sixty five and Azure. You now know what the tool is and where it breaks. So let's put it on the map, because the map is what makes the rest of Microsoft's world feel less random. SharePoint and Microsoft Lists are the data home, and they share one engine, so there's no separate database to stand up. You don't pick a database, you pick a list. And that's the whole setup. Cost teams is where the app can live. If the team already works in a channel, the app can sit there and people find it without being told to go somewhere new. Power automate is the automation half of the pair. It can watch a list and act when a row is added or changed, and the app can start a flow from a button. That's how a request becomes a notification, and it's the combination most teams land on. First power BI reads the same list for reporting, which is the payoff of keeping your data in one place. One list can feed an app for the people doing the work, and a dashboard for the people watching the numbers with nothing copied in between. Dataverse is the premium data platform you reach for when a list isn't enough, and it's the same step up we ran into at the five hundred record wall. Then there's Azure, which beginners ask about constantly. Power platform runs on Microsoft's cloud, so there are no servers for you to patch or scale. And in that sense, you're already using Azure without touching it. Azure shows up underneath and you only go looking for it directly on the day you build something that needs those services itself. That's the shape of it. SharePoint holds the rows. PowerApps gives them a front door, power automate moves them, power BI explains them, and Dataverse and Azure wait for the day a list stops being enough. The short version and a question for you. So let's put it back together in a few sentences. A SharePoint list holds your data power apps, puts a friendly app on top of it, and you can generate the first working version in a couple of clicks without writing code. The two numbers worth remembering are five hundred, where a formula that can't reach SharePoint stops being trustworthy, and five thousand where a SharePoint view starts refusing to do the work. And here's the question I'd like you to answer. What's the one list in your team that everybody complains about, and what would it look like with a proper app in front of it? Tell me in the comments, because those answers are where the next episode usually comes from. If this made the topic feel less intimidating, subscribe to M365 FM to master the tools and the mindset shaping the future of work.