Power Apps Portals for External Users

Power Apps Portals is a feature in the Microsoft Power Platform that lets you build low-code websites. The key word is "portals." The phrase comes from the idea of a grand entrance — a door that leads somewhere specific. In this case, the portal is a door that leads into your business data, but only for people who do not work for your company. These are "external users."

To understand why this matters, think about what happens without a portal. Suppose you run a charity that accepts applications for grants. Today, you might have an internal app built in Power Apps that your staff uses to review applications. But how do applicants submit their application in the first place? Traditionally, you would either build a custom website from scratch (expensive and slow) or make applicants email documents (chaotic and insecure). A Power Apps Portal solves this by giving you a ready-made website template that connects directly to the same Microsoft Dataverse database your internal apps use. Applicants see a form on the portal, fill it out, and the data goes straight into the same database your staff uses. No duplicate data entry, no emailing spreadsheets, no custom coding.

The portal website is hosted by Microsoft. You do not need to manage web servers or buy domain hosting. You build the portal using a drag-and-drop editor inside Power Apps, and you control which pages visitors can see. You can add forms that let users submit data, lists that let them view records, and even custom web pages with your company branding.

Security is handled through authentication. This is the process of verifying who someone is. Out of the box, Power Apps Portals supports several ways for external users to prove their identity:

Once a user is authenticated, the portal uses something called "web roles" to control what they can see and do. A web role is like a membership card that grants specific permissions. For example, you might create a web role called "Customer" and another called "Partner." A customer can only view their own orders; a partner can view orders for all their clients. You assign these roles to users manually or automatically based on their email domain or registration answer.

The portal also includes a content management system. You can publish news articles, FAQ pages, and static web content without writing code. This makes the portal useful not just for data entry but also for communication. For example, a company might use a portal to announce product recalls to registered customers, or a university might post semester schedules to a student portal.

Critically, the portal is not just a read-only window. External users can create, read, update, and delete records in Dataverse — but only the records they are permitted to see. This is managed by the same security model you use for internal apps: column-level security and row-level security. So a customer cannot delete someone else's order, even if they accidentally stumble across the URL.

Portals can also be extended with custom code. If your business needs a complex workflow — for instance, an applicant who needs to upload a PDF, get it reviewed by three managers, and then receive a signed approval letter — you can use Power Automate flows or custom JavaScript to add that logic. However, the PL-900 exam does not require you to know how to write that code. It only expects you to know that portals can be customised.

Finally, the most important thing to remember for the exam: a Power Apps Portal is for external users. If you need an app for your own employees, you build a canvas app or a model-driven app. If you need a website for customers, you build a portal. They are different tools for different audiences, even though they share the same underlying data and platform.

A mid-sized healthcare equipment supplier, MedSupply Ltd, decides to replace its paper-based repair request process. Currently, hospital technicians who need a part repaired must phone MedSupply, speak to a customer service agent, who then manually enters the request into an internal system. This process is slow and error-prone. The company wants to let hospitals submit repair requests directly through a website.

An IT consultant suggests using Power Apps Portals. Here is how the project unfolds, step by step.

First, the consultant opens the Power Apps maker portal and creates a new portal from a template. They select the "Customer Self-Service" template, which already has pages for submitting requests, viewing request status, and updating profile information. This saves weeks of design work.

Next, they configure authentication. The hospitals already use Microsoft Entra ID for their email systems. The consultant enables Microsoft Entra ID authentication (now Microsoft Entra ID) in the portal settings. When a hospital employee visits the portal, they are redirected to their organisation's Microsoft login page. After signing in, they are sent back to the portal with their identity confirmed. No separate password to remember.

Once the portal knows who the user is, the consultant must decide what data that user can see. The underlying data is stored in Microsoft Dataverse tables: a "Repair Request" table and a "Customer" table. The consultant uses the portal's security settings to create a web role called "Hospital Technician." They then configure row-level permissions so that a technician can only see repair requests that belong to their own hospital. If a technician logs in and views the "My Requests" page, they see only their hospital's tickets. They cannot browse other hospitals' data.

The consultant then adds a web form to the portal. They drag a Dataverse form onto a page called "Submit New Repair." The form includes fields like equipment name, serial number, and issue description. They configure the form so that when a technician submits it, a new record is created in the Dataverse table and automatically assigned to the MedSupply internal team.

To make the portal look professional, the consultant customises the theme. They upload MedSupply's logo, change the colour scheme to match the corporate blue, and add a footer with legal disclaimers. They also add a static page called "Warranty Information" that is visible to all visitors, even those who have not logged in. This is an "anonymous" page, accessible without authentication.

Once the portal is built, the consultant publishes it. MedSupply now has a live website at, for example, parts.medsupply.com. The consultant sends a test invitation to one hospital technician. The technician logs in, submits a dummy repair request, and within seconds, the internal support team sees the new record in their model-driven app. No phone call, no paper form, no delay.

What does the IT professional actually do with this? They maintain the portal over time. They add new web forms when the company introduces a new service line. They monitor portal usage using the built-in analytics to see which pages are most visited. They troubleshoot login issues when a user from a new hospital tries to access the site but cannot sign in because their domain has not been added to the allowed list. They assign web roles to new users, and occasionally they write a small JavaScript snippet to pre-populate a form field based on the user's email address. The portal, once built, runs itself — but the IT professional is the gatekeeper who ensures only the right people see the right data.