Power Apps is Microsoft’s low-code platform for building custom business apps that run in a browser and on phones. It connects to data you already hold in SharePoint, Excel, SQL Server or Dataverse and it comes with most Microsoft 365 plans. For an Australian business the question that matters more than what it can build is what happens to the app after the person who built it moves on.
Table of Contents
What is Power Apps used for in a business?
Power Apps is used to replace the forms, spreadsheets and email chains that hold a process together. Typical builds are quoting tools, inspection and site forms, job and asset registers, approval apps, onboarding checklists and stock counts. The common thread is a process that already exists and is being run by hand across several files.
Microsoft’s own description is that apps built with Power Apps “provide rich business logic and workflow capabilities to transform your manual business operations into digital, automated processes”, according to the Power Apps overview on Microsoft Learn. In plainer terms, the app puts a screen and some rules in front of data that was previously typed into a spreadsheet, a paper form or somebody’s inbox.
That framing matters because Australian businesses are already spending significant money on this problem without seeing the return. The Australian Industry Group’s 2026 outlook, a survey of 225 private-sector leaders in October and November 2025, found technology remains the leading investment priority, with 49% of businesses planning to increase spending and that improving operational processes is the top cost management strategy at 36%. Meanwhile CPA Australia’s Asia-Pacific Small Business Survey, released 2 April 2026, found only 30% of Australian small businesses said their technology investment in 2025 improved profitability. Money is going into technology faster than profit is coming back out of it.
Power Apps earns its keep when the app is built around a process that a business already runs and understands. A quoting database rebuild for a regional New South Wales promotional products supplier, covered in the project section of this post, is a good example: two decades of pricing rules and freight bands, moved out of a locked Access file and into an app the business can now change itself. The starting point was that nobody could touch the quoting system, rather than a wish for an app.
A spreadsheet is often where the process lives today. Our guide to moving a spreadsheet process into Power Apps works through the three paths for doing that, so this post will not repeat them.
What are the types of Power Apps?
Power Apps has two app types, canvas apps and model-driven apps. A third product, Power Pages, is often grouped with them because it builds external-facing websites on the same data platform and is licensed separately. Which type you need depends on whether you start from a screen design or a data model and on who will use the app.
Microsoft’s own overview states that “you can create two types of apps: canvas and model-driven” and its overview of creating apps describes where each starts.
Canvas app
A canvas app starts with the user experience. You draw the screens, place the controls and connect each one to data. Microsoft describes canvas apps as connecting to “your choice of more than 200 data sources” and running on web, mobile and tablet. This is the type most small and mid-sized Australian businesses end up with, because it can sit on top of SharePoint Lists or an Excel table without moving the data first and because the screens can be made to look like the paper form staff already know.
Model-driven app
A model-driven app starts with the data. You define the tables, relationships and business rules in Dataverse and the app generates its forms and views from that structure. Microsoft’s wording is that model-driven apps “start with your data model” and “automatically generate a great UI that’s responsive across devices”. They suit case management, registers and compliance work where role-based security matters more than a bespoke layout. Our model-driven apps guide covers when that trade is worth making.
Power Pages
Power Pages is not a Power Apps type, though it is sold and built alongside them. Microsoft defines it as a “low-code software as a service (SaaS) platform” for “external-facing business websites”, per the Power Pages introduction on Microsoft Learn. If the people using the app are customers or members of the public rather than staff or a few named partners, Power Pages is the tool. Our comparison of Power Pages and Power Apps sets out where that line falls.
Where does a Power App keep its data?
A Power App does not store business data inside the app. It reads and writes data held in a data source, most often SharePoint Lists, an Excel table, SQL Server or Microsoft Dataverse. The choice of data source decides how far the app can scale, what licence users need and how much of the logic can live outside the app.
Five sources cover most Australian builds.
SharePoint Lists. Included with Microsoft 365, familiar to staff and the default home for a first app. Lists suit hundreds to tens of thousands of rows per list and simple relationships. A quoting app we rebuilt for a regional New South Wales promotional products supplier runs on 14 SharePoint Lists holding more than 100,000 records, so the ceiling is higher than people assume, provided the app is built to work with it. In practice that means every column the app filters or sorts on is indexed, because SharePoint’s List view threshold is configured at 5,000 items by default and queries that exceed it are refused and it means the formulas stay delegable.
Excel. Fine as a starting point but a poor long-term home. Microsoft’s troubleshooting guidance notes that Excel data “must be formatted as a table” to work with Power Apps and a shared workbook that people also edit by hand is a data source that changes underneath the app.
SQL Server and Azure SQL. The right choice when the data is already relational, when volumes are large or when other systems need the same tables. Both are premium connectors, which affects licensing.
Dataverse. Microsoft’s own data platform for the Power Platform. Its Dataverse overview describes it as letting you “securely store and manage data that’s used by business applications”, with role-based security, business rules and relationships defined once and applied to every app that touches the table. It is the required home for a model-driven app and the strongest option when several apps, flows and reports share the same data. The Dataverse tables explainer goes into how tables, relationships and security fit together.
Dataverse for Teams. A smaller version of Dataverse that Microsoft describes in its Dataverse for Teams overview as included “in most existing Teams licenses”, with “storage of 2 GB per team” and “support for up to 1 million rows”. It gives a canvas app relational tables under a Microsoft 365 licence. The trade is that the app runs inside Teams under that licence, cannot use custom connectors and has no API access. Premium connectors still need premium use rights for every user and model-driven apps are not available on it. Run the same app outside Teams and every user needs a per-app or per-user plan. For an internal register used by staff who already work in Teams it is often the right middle step between SharePoint Lists and full Dataverse.
One more data-source consequence is easy to miss. If anyone will use the app where there is no signal, the choice is largely made for you. Microsoft’s offline limitations for canvas apps state that “non-Dataverse connectors, like SharePoint, aren’t supported in offline mode” and Microsoft’s offline guidance notes that built-in offline runs only in the Power Apps mobile app. That means full Dataverse, because Dataverse for Teams does not support mobile offline either. A SharePoint app can cache small amounts of data on the device through the LoadData and SaveData functions, but the maker has to write that logic and handle reconnection.
How the app talks to each source is through a connector and our guide about how Power Apps works covers connectors in more depth than this overview does.
Is Power Apps included in Microsoft 365 and how is it licensed?
Yes, a limited version of Power Apps is included with most Microsoft 365 business and enterprise plans. That covers apps using standard connectors such as SharePoint and Excel. An app that uses a premium connector, a custom connector or an on-premises gateway needs premium use rights for every user, through a per-user plan, a per-app plan or pay-as-you-go billing.
Microsoft’s licensing overview for Power Platform lists what the Microsoft 365 plan includes: create, run and share apps, connect to Microsoft 365 data and “connect to cloud services using standard connectors”. The same table marks “access on-premises data or use premium or custom connectors” as not included. Microsoft’s licensing FAQ is blunter, stating that a standalone Power Apps or Power Automate plan licence is required to access all premium, on-premises and custom connectors.
In practice this makes the data source decision a licensing decision as well, because an app on SharePoint Lists runs under the licence staff already have. Microsoft’s licence designation page sets out the rule: an app is designated Premium if it uses at least one premium connector, a custom connector or an on-premises gateway and a Premium app requires a per-app or per-user plan to access. Pay-as-you-go is the third route.
So it is worth being careful about calling Power Apps free. It is free to build under Microsoft 365 and often free to run, but once the app needs SQL Server, full Dataverse or a connection into an on-premises system, it has a cost that scales with the number of people who need premium use rights rather than with the company’s headcount. A per-user plan covers a named user across every premium app, a per-app plan covers only the users assigned to the app and Microsoft’s licensing FAQ describes pay-as-you-go as letting users run an app “without any licenses via an Azure subscription”, paying only for the users who opened it that month. One date matters on the per-app plan: Microsoft removed it from its public price list on 2 January 2026, so from that date a new customer buys it through a Cloud Solution Provider partner rather than directly. It is also worth settling the licence designation before the build rather than after, because switching a live app from a standard to a premium data source changes what every user must hold. There is a hard date behind this. Microsoft’s licensing compliance FAQ states that from February 2027 users without an appropriate premium licence “can’t open and use the app until an appropriate license is assigned”, naming model-driven apps and apps in managed environments among the areas where the requirement had previously been applied leniently.
Specific plan prices are deliberately left out of this post. They change, they differ by agreement and Microsoft’s pricing page is the only source worth quoting on the day you need the number.
Power Apps, Power Automate or custom code: how do you decide?
Choose Power Apps when people need screens to work through. Choose Power Automate when the work is a sequence of steps triggered by an event and nobody needs to look at it. Choose custom code when the volume, the interface requirements or the integration depth exceed what a low-code platform can carry. Most real solutions use two of the three.
Power Apps and Power Automate are complementary rather than competing and the comparison of Power Apps and Power Automate already works through that pairing in detail. This section covers the decision that comparison leaves open: Power Apps against a custom-built web app and against the legacy tools it usually replaces.
The table below compares Power Apps with a custom web app and with a Microsoft Access database on the questions that decide most Australian builds.
| Question | Power Apps | Custom web app | Access database |
|---|---|---|---|
| Who can change it after go-live | A trained staff member if the rules live in data, otherwise a Power Apps builder | A developer | Anyone with Access skills, unless it was compiled and the source is lost |
| Licence model | Included with Microsoft 365 for standard connectors, per user, per app or pay-as-you-go once a premium connector is used | None beyond hosting and development | Included in some Microsoft 365 plans, Windows desktop only |
| Runs on phones | Yes, through the Power Apps mobile app | Yes, if built responsive | No |
| External users | Named guests with a matching licence, Power Pages for the public | Yes | No |
| Large data sets | Depends on delegation and data source | Limited only by the design | 2 GB per file, more with a SQL Server back end |
| Best fit | Internal processes on Microsoft 365 data | Public-facing products, high volume, bespoke logic | Desktop tools for a small team on Windows |
The Access ceiling in that table is Microsoft’s documented maximum of two gigabytes for an Access database, per the Access developer reference. The external users row reflects that Microsoft’s guest sharing documentation allows a canvas app to be shared with external business partners, contractors and third parties invited as guests in your Microsoft Entra tenant, provided each holds a licence that matches the app. Power Pages is for people you cannot name in advance. The Access column is there because a great many Australian business tools still live in it and because the question “should this be a Power App” is usually asked about an Access database or a spreadsheet that has outgrown its owner. Our legacy modernisation work covers that route and custom web apps covers the cases where low-code is the wrong ceiling.
What are the limitations of Power Apps?
Power Apps has four limitations that matter in practice: a data row limit that silently returns wrong results, a licence designation that can change mid-project, dependence on whoever built the app and a governance gap when apps are created outside IT. None is a reason to avoid the platform, though each is a reason to plan the build properly.
Delegation. When a formula cannot be handed to the data source to run, Microsoft’s delegation documentation states that Power Apps “gets the first 500 records from the data source and then runs the actions in the query” and that the limit can be raised to 2,000. The same page warns that “the query might return incorrect results if the data source has more than 500 or 2,000 records”. Rather than failing, the app shows a partial answer that looks complete. On a quoting app with a pricing list of more than 75,000 rows, a non-delegable filter would return either no price or a price from a row in the first 500, with no error at runtime. The editor usually flags it: Microsoft’s data source guidance notes that a non-delegable formula is marked with a warning triangle in the editor, though the same page says not every non-delegable case shows the warning. The warning is also easy to click past, because the app works perfectly until the data grows past the limit, which is why this defect is so common in apps built by an enthusiastic staff member.
Licensing drift. An app that starts on SharePoint Lists and is later pointed at SQL Server moves from a standard to a premium designation and every user then needs premium use rights they did not need before. Businesses tend to discover this when staff open an app that worked last week and are asked for a licence, or when the first premium bill arrives.
Maker dependency. Low-code lowers the barrier to building. It does not lower the barrier to understanding what was built. An app assembled over six months by one person carries that person’s assumptions in every formula and when they leave the business inherits an app it cannot safely change. It is the same problem Access databases have had for twenty years, in a newer tool, and switching platforms does not solve it. What does is naming conventions, documentation and a handover that treats the app as a business asset rather than a personal project.
Governance. Because anyone with a Microsoft 365 licence can build, businesses end up with apps nobody in IT knows about, connected to data nobody approved. Data loss prevention policies, a register of production apps and separate environments are dull work, but they are what keeps a platform from turning into a sprawl. One caveat on environments: Microsoft’s environment documentation lists Microsoft 365 plans as unable to create production environments and creating one also needs spare Dataverse capacity that a Microsoft 365 only tenant usually lacks. Check that page before assuming you can and if you cannot, treat the default environment as production.
The four limits above can be planned around. Three other cases cannot: high volume, public users and complex integration. There the answer is a custom web app rather than a bigger Power App and it is far cheaper to say so at the start than to rebuild later.
What does a Power Apps project look like from scoping to handover?
A Power Apps project runs through five stages: map the process, decide the data source and licence designation, build a first version against real data, test it with the people who will use it, then hand it over with documentation. The build is often the shortest stage and most of the value is won or lost in mapping and handover.
The stages in order:
- Map the process as it runs today, rather than the ideal version: who enters what, where the exceptions go and which spreadsheet is the real source of truth.
- Decide the data source and the licence designation together. SharePoint Lists for a standard app, Dataverse for Teams if running inside Teams under a Microsoft 365 licence is enough, full Dataverse or SQL for a premium one. Confirm what every user will need to hold before a screen is drawn.
- Build a first version against real data. Sample data hides delegation problems. A copy of the live data set surfaces them on day one.
- Test with the people who will use it, on the devices they will use. A form that works on a desktop and fails on a phone in a warehouse has not been tested.
- Hand over with documentation and named owners. Move ownership of the app and every supporting flow to an internal account rather than the consultant’s and re-create the connections under it. Export the solution so the source is on file. Record which lists or tables the app depends on, which formulas still carry business rules and who is expected to change what.
One build shows why the decisions made before the first screen matter more than the build itself. A promotional products supplier in regional New South Wales ran quoting through a Microsoft Access front end over SharePoint Lists. The front end had only ever been handed over compiled and the developer who built it was no longer contactable. The Access to Power Apps rebuild moved the quoting logic into a Power Apps canvas app built directly on the 14 SharePoint Lists the old system already used, keeping 100,000+ live records in place rather than migrating them. The app carries 38 freight bands, a 647-product catalogue and a pricing list of more than 75,000 rows and a Power Automate flow generates 3 PDFs per order. The change that mattered to the business was that pricing rules and freight rates could now be edited in-house rather than by a developer nobody could reach and that came from a design choice made before the build: the rules were moved out of code and into Lists the app reads. Keeping rules in data rather than in formulas is what lets an app outlive its builder and it is worth asking for when you commission one.
That, more than any feature list, is what Power Apps for business comes down to: an app the business can keep running without the person who built it. Our Power Apps development services are built around that outcome and the wider custom apps, portals and intranets practice covers the cases where Power Apps is only part of the answer.
Frequently asked questions
Is Power Apps easy to learn?
Building a simple canvas app on a SharePoint list is within reach of a confident Excel user, because the formula language borrows Excel’s shape. Building one that stays correct as the data grows is harder. The editor usually flags a non-delegable formula with a warning that is easy to click past and at runtime there is no error at all, so the first sign is a wrong number in front of a customer. Expect the first app to be easy and the first production app to need help.
What are the three types of Power Apps?
Microsoft documents two types, canvas apps and model-driven apps. The third that people count is Power Pages, which builds external-facing websites on Dataverse and is licensed separately. Canvas apps start from the screen, model-driven apps start from the data model and Power Pages serves users outside the organisation.
Do I need a licence to use a Power App someone else built?
Yes. Microsoft’s overview states that you need a licence to play the apps made with Power Apps. If the app uses only standard connectors, a Microsoft 365 plan that includes Power Apps is enough. If it uses a premium connector, a custom connector or an on-premises gateway, each user needs premium use rights through a per-app plan, a per-user plan or pay-as-you-go billing on an Azure subscription and from February 2027 Microsoft blocks users without one from opening the app.
Can Power Apps replace an Access database or a spreadsheet?
Often, yes, and it is one of the most common reasons an Australian business adopts it. The data usually moves to SharePoint Lists or Dataverse and the forms, rules and reports are rebuilt as app screens. The rebuild described in this post moved a quoting database holding two decades of trading logic without migrating its 100,000+ records. Not every Access feature has a direct equivalent, so map the process before committing.
How long does a Power Apps build take?
A single-purpose app on an existing SharePoint list can be scoped and built in a few weeks. An app replacing a quoting system, a register with role-based security or anything on Dataverse takes longer and most of the extra time goes into mapping the process and cleaning the data rather than building screens.
Is Power Apps secure enough for business data?
On SharePoint and Dataverse the app runs under each user’s own identity and permissions. On SharePoint that cuts both ways, because a user who can edit through the app can also open the list directly and bypass the app’s rules. If a rule must be enforced, the data belongs in Dataverse, where role-based, row-based and column-based security sit on the table. A SQL authentication connection runs under the maker’s credentials rather than the user’s, so SQL Server cannot tell users apart and per-user rules must be enforced another way.
Is Power Apps right for your business?
Power Apps is the right tool when a process already exists, the data already sits in Microsoft 365 and the people using the app are staff. It is the wrong tool for public users, high volumes and integration-heavy work. The decisions that matter, data source, licence designation and who owns the app after go-live, are made before the first screen.
If a spreadsheet, an Access database or an inbox is quietly running a process your business depends on, book a free call and we will map it with you and tell you plainly whether Power Apps is the answer.
