What is Power Apps?

Power Apps is Microsoft's low-code platform for building business applications without a full software-development project. It's part of the Power Platform, alongside Power Automate, Power BI, and Copilot Studio, and for Microsoft 365 organisations it's the standing answer to a very common request: "we need a small line-of-business app, and IT's development queue is eighteen months long."

That request is also why Power Apps shows up in your tenant whether you planned for it or not. The licence rights are seeded into Microsoft 365, the maker portal is a click away, and the first apps appear long before anyone writes a governance policy. Understanding what the platform is — and what it costs once apps get serious — is now baseline M365 admin knowledge, not a specialist niche.

The three app types

Power Apps is really three products under one name, and choosing the wrong one is the most common early mistake.

Canvas apps are the drag-and-drop kind. You start from a blank screen, place controls wherever you want, connect them to data sources (SharePoint, Dataverse, SQL, Excel, hundreds of third-party services), and wire behaviour with Power Fx — a formula language deliberately shaped like Excel's. Canvas apps excel at focused, task-shaped tools: inspections, site visit forms, approval front-ends, lookup utilities, anything that replaces a paper form or a shared spreadsheet. They get painful when the data model grows past a handful of related tables.

Model-driven apps flip the approach: you design the data model in Dataverse and the app is generated from it — forms, views, dashboards, and business process flows derived from the tables. You give up pixel-level control and gain speed and consistency for record-management applications: case handling, asset registers, request tracking. Dynamics 365's apps are model-driven apps with Microsoft's own data model; the sister-site guide on Dynamics and the Power Platform covers that relationship.

Power Pages (formerly Power Apps portals) are externally facing websites backed by Dataverse, with authentication for people outside your tenant. Partner portals, customer self-service, grant applications, event registration. It's licensed and operated quite differently from the other two — treat it as an adjacent product, not a checkbox feature.

The full decision between the first two is in canvas vs model-driven apps. The short version: canvas for tasks, model-driven for records.

Dataverse is the fork in the road

Every serious Power Apps conversation arrives at Dataverse, the platform's relational database. It brings real tables, role-based and row-level security, auditing, business rules, and APIs — everything a SharePoint list quietly lacks once an app matters.

It's also the licensing trigger. Apps built on SharePoint lists run on seeded Microsoft 365 rights; apps built on Dataverse need premium licences. That makes "SharePoint list or Dataverse?" a cost decision as much as an architecture one. The honest guidance: prototypes and small tools on SharePoint lists are fine; anything with security requirements, volume, or more than a few related tables belongs in Dataverse, and the licence cost is the price of it not falling over later.

What's actually included with Microsoft 365

The seeded rights confuse everyone, so here is the practical line:

• Included: canvas apps using standard connectors — SharePoint, Excel, Outlook, Teams, and the rest of the in-suite services. This is genuinely useful and covers a lot of form-replacement scenarios.
• Premium (paid): anything touching Dataverse, SQL, custom connectors, on-premises gateways, or most third-party services; all model-driven apps; Power Pages.

Premium licensing comes per user (one user, unlimited apps) or per app (cheaper, one user–one app), plus pay-as-you-go metering through Azure. Which one wins depends entirely on how many apps your users touch — the arithmetic and the traps live in Power Platform licensing explained.

The governance part you can't skip

Because makers can build apps without asking IT, the platform needs guardrails before it needs a roadmap: environments to separate development from production, DLP policies to stop a well-meaning flow from piping payroll data into a personal Dropbox, and an inventory so you learn about business-critical apps before their maker resigns. That's the territory of environments and governance and DLP policies — and the reason this guide opens the Power Platform governance learning path.

One prediction that holds in almost every tenant: the first business-critical Power App is discovered, not announced. Someone builds a tool, a department comes to depend on it, and IT finds out when it breaks. Governance is how you find it earlier.

When not to use Power Apps

• High-volume or public-scale applications — Power Apps is priced and engineered for internal business apps, not consumer traffic.
• Complex custom UX — if the design spec has more than a passing opinion about interaction detail, canvas apps will fight you. See performance tuning for how much care big canvas apps need.
• Anything a product already does — a surprising share of app requests are Planner, Lists, Forms, or a Teams workflow wearing a trench coat. Check first.

Where it fits

For Microsoft 365 organisations, Power Apps is the fastest route from "we track this in a spreadsheet and it hurts" to a working, mobile-friendly app with real security — embedded in Teams, automated with Power Automate, and reported on with Power BI. The trade-offs are platform lock-in and a licensing model that changes shape as apps mature. Accept both consciously, put governance in early, and it's one of the highest-leverage tools in the stack.