Power Pages

What is Power Pages?

Power Pages is the part of Microsoft Power Platform for external websites that work with business data. You can build a portal where customers, suppliers, members or citizens view information, fill in forms and track the status of a request. It was previously known as Power Apps portals.

The site uses Microsoft Dataverse as its data layer, so the same request can also appear in an internal Power App, a Power Automate flow and a Power BI report. Power Pages adds web pages, navigation, forms, sign-in and access rules around that data.

A site can be fully public, restricted to signed-in visitors, or a mix of both. It is more than a website builder for marketing pages: the strongest uses put a real process and protected data behind the site.

How Power Pages is built

In the design studio you assemble pages, text, forms, lists, colours and navigation. Forms and lists can show or change Dataverse data directly. For anything more, Liquid templates, JavaScript, the portals Web API and code components are available.

A visitor who signs in is linked to a contact record in Dataverse. Web roles group visitors by their function, such as customer, supplier or case handler. Table permissions then decide which records those roles may read, create, write or delete, and you can scope that access to a record's relationship with the visitor's own contact or account.

Page permissions control who can open a page, which is a separate check from access to the underlying table. A hidden page without the right table permissions does not protect the data, so both layers have to line up. When something needs following up, a Power Automate flow can update the record, start a check and notify the responsible person.

Examples of Power Pages sites

Customer request portal

A customer signs in, submits a request and attaches documents. The customer sees only their own cases, while an internal team handles the same records in a model-driven app. A status change starts an email or a task through Power Automate.

Supplier portal

Suppliers maintain their contact details, certificates and bank information. Dataverse stores the records and ties them to the right organisation, and web roles with table permissions make sure one supplier cannot open another supplier's data.

Member portals, event registration, self-service support and public registers work the same way. The common thread is that external visitors take part in a business process under controlled access.

Power Pages versus Power Apps

Power Apps aims mainly at staff and other users inside or closely tied to the organisation. Those apps run in Power Apps, Teams or a browser and use the Power Platform licensing and security model.

Power Pages aims at external web visitors. The site has its own domain, web navigation and sign-in options, and it can also serve anonymous content. Protected Dataverse data reaches visitors through web roles and table permissions rather than through security roles alone.

For an internal case app, a model-driven app is usually more direct. For a portal with customers and suppliers, Power Pages fits better. Often you run both on the same Dataverse model: the customer files a request from outside, and a staff member handles it inside.

Power Pages versus a custom website

Power Pages gives you hosting, the Dataverse link, identity integration and visual designers as a managed service. That can save real work when the portal is part of a wider Power Platform solution.

A custom website hands a development team full control over technology, performance and experience. That fits a public digital product with a very specific interface, or an architecture that does not revolve around Dataverse. The trade is also about upkeep: a Power Pages site needs knowledge of Dataverse permissions and Power Platform environments, while a custom site needs its own hosting, deployment, security updates and integrations. Neither option removes the need for someone to own it.

Security, privacy and going live

Start from least access. Give a web role only the table permissions it needs and limit records through the right relationship with the contact or account. Test with different accounts, including a visitor with no role and an anonymous session, because a public site with the Anonymous role on a table exposes that data to everyone.

Check which personal data you collect, why you need it and how long you keep it. Data minimisation and data retention still apply under the GDPR even when the platform handles the forms and storage for you. For sensitive processes, logging, consent and a DPIA belong in the assessment.

A new site is not automatically ready for the public while it is being built. Before go-live, review site visibility, identity providers, web roles, table and page permissions, custom code, domain settings and licensing, and add failed automations and expired documents to your monitoring.