Overview of Power Apps and App Types

Power Apps is Microsoft’s low-code application development platform, meaning you can build apps by dragging and dropping components rather than typing out complex programming languages like C# or JavaScript. The core idea is to empower business analysts, project managers, and other non-developers to create functional apps that solve real problems — without relying on a dedicated IT team. Within Power Apps, there are three primary app types: canvas apps, model-driven apps, and portals. Each serves a different purpose and comes with its own strengths and trade-offs.

Canvas apps let you design the user interface from scratch — you start with a blank screen and drag elements like buttons, text inputs, galleries (lists of records), and images onto a canvas, similar to designing a slide in PowerPoint. The name comes from the art metaphor: you have complete creative control over the layout, colours, and flow. Because you are arranging everything manually, canvas apps are ideal for scenarios that require a highly customised user experience, such as a field-service app where a technician needs to see a map, scan a barcode, and log a repair in a specific order. Canvas apps can connect to hundreds of data sources, including SharePoint lists, Excel files stored in OneDrive, SQL databases, or Microsoft Dataverse. However, because the layout is handcrafted, they do not automatically adapt to changes in the underlying data structure — if you add a new column to your SharePoint list, you have to manually update the app to show it.

Model-driven apps, by contrast, are built around your data. Instead of starting with a blank canvas, you start with a data model in Microsoft Dataverse (a cloud-based database that stores your business data in a secure, structured way). You then define the app’s components — forms, views, dashboards, and business process flows — and the system automatically generates the user interface based on that data structure. The result is a responsive, uniform interface that works well across browsers and mobile devices without extra design work. A model-driven app’s layout is not freeform; it consists of a sitemap (navigation menu) that leads to different entities (think “tables” like Accounts or Opportunities), each with standardised views (like “My Open Leads”) and forms. This makes model-driven apps perfect for back-office tasks such as managing a sales pipeline, tracking customer support cases, or processing employee leave requests — scenarios where data consistency and business logic matter more than a flashy interface. A key characteristic is that model-driven apps are always built on Dataverse, so they inherit its security, role-based permissions, and built-in business rules.

Portals (often called Power Pages in newer releases) are outward-facing websites that allow external users — customers, partners, vendors — to interact with Dataverse data without needing an internal Microsoft 365 license or Power Apps experience. Think of a portal as a window into your business system for people who don’t work at your company. For example, a training portal where learners can register for courses, view their progress, and download certificates — all by logging into a public website. Portals are built using a design studio similar to a website builder, and they support branding, custom templates, and content management. They are ideal when you need to let thousands of anonymous or authenticated external users access specific records (like their own support tickets) without granting them access to your entire Microsoft environment.

Beyond these three, there is also a distinction between environment and solution. An environment is a container in which Power Apps, Dataverse, and other Microsoft Power Platform components are stored and managed. A solution is a package that moves apps, flows, and other components from one environment to another (for example, from a development environment to production). You do not need to master these details for the basics, but they are part of the ecosystem.

Why does Power Apps matter? Traditionally, building a custom app meant hiring a software developer, writing code, setting up servers, and managing updates — a process that could take months and cost tens of thousands of dollars. Power Apps reduces that to days or even hours, and because it runs on Microsoft’s cloud infrastructure (Azure), you do not have to worry about hardware or hosting. The PL-900 exam expects you to know the differences between these app types so you can recommend the right one for a given business requirement — and so you understand that there is no single “best” type, only the one that best fits the problem.

Imagine you work as a business analyst for a mid-sized manufacturing company called Contoso Ltd. The operations manager asks you to build a digital tool to track equipment maintenance in the factory. Currently, technicians use paper forms and email to report when a machine breaks down. This process is slow and error-prone — the manager wants a mobile-friendly solution that field engineers can use at the machine, and that also gives the office a dashboard of open repairs.

Here is how an IT professional (or a citizen developer like you) would approach this scenario using Power Apps:

Step 1: Choose the right app type. The requirement is a mobile-friendly tool for field use and a data view for the office. A canvas app is the best fit because it gives you total control over the mobile interface — you can place a large “Report Breakdown” button on the home screen, add a barcode scanner component to identify the machine, and create a gallery showing recent jobs. A model-driven app would lock you into a standard list-and-form layout that is less intuitive for a tap-and-swipe field environment. So you start by creating a new canvas app in the Power Apps maker portal.

Step 2: Connect to data. You decide to use a SharePoint list named “MaintenanceLog” with columns for Machine ID, Description, Status, and Technician. In Power Apps, you click “Add data source” and choose SharePoint. You select your site and the MaintenanceLog list. The app now has read/write access to that list.

Step 3: Design the interface. You drag a gallery control onto the screen and set its Items property to the SharePoint list. This automatically shows each maintenance record. You customise the template to display the machine name and status. You add a button labelled “New Record” and, on its OnSelect property, write a formula like Navigate(NewScreen) — this brings up a separate form screen where the technician fills in details and taps “Submit” to create a new SharePoint item. You also add a barcode scanner using the Power Apps Barcode Scanner control.

Step 4: Add business logic with Power Automate. You want an email alert sent to the maintenance manager whenever a high-priority breakdown is logged. You create a Power Automate flow triggered by the creation of a SharePoint item with Priority = “High”. The flow sends an email via Outlook. In the canvas app, you call this flow from the button’s OnSelect property.

Step 5: Deploy and secure. You assign permissions in SharePoint so technicians can only view their own records (using the “Edit permissions” in the app’s formula to filter by the current user’s email). You then share the app with the technicians by sending them a link. They can open it on their phone via the Power Apps mobile app or a browser.

Step 6: Monitor and iterate. After two weeks, the manager asks for a dashboard showing the average time to repair. You add a second screen with charts (using the Charts control in Power Apps) that summarise data from the SharePoint list. No code change, just a few clicks.

In this scenario, the IT professional never wrote a single line of traditional code. They used Power Apps’ low-code tools, connected to an existing data source (SharePoint), and rapidly delivered a solution that replaced a manual process. The PL-900 exam will test your ability to recognise which app type fits such a scenario — and why you would not choose a model-driven app or a portal for this.