Power Pages (formerly “Power Apps Portals”) is Microsoft’s low-code platform for building external-facing websites backed directly by Dataverse — letting customers, partners, or the public interact with your data without ever touching the internal model-driven app or needing a full Dataverse license.

Why it exists

Model-driven apps assume an internal, licensed user. Power Pages exists for everyone else: a customer checking their support case status, a partner submitting an order, a job applicant filling out a form — people who shouldn’t have (and often legally can’t have) a seat inside your internal system, but still need to read or write specific Dataverse data.

What a Power Pages site is made of

  • Pages — individual web pages, built from web templates, arranged in a navigable site structure.
  • Lists — grid-style views of Dataverse records, the portal equivalent of a model-driven view.
  • Forms — for creating or editing Dataverse records from the portal.
  • Table Permissions — a completely separate security layer controlling what portal visitors can access (covered in depth later in this course).
  • Web roles — portal-specific roles (distinct from internal security roles) assigned to authenticated portal Contacts.
The most important thing to unlearn coming from model-driven apps. Internal security roles and business units have no effect on a Power Pages site. Portal access is governed entirely by its own separate mechanism — table permissions and web roles. Assuming internal security automatically protects portal data is a serious, common misconception, and getting it wrong means exposing data publicly by accident.

Low-code, with a real escape hatch

Most of a typical site is built visually (pages, lists, forms, navigation) without code. For anything beyond that, Power Pages supports Liquid templating (covered later) and custom HTML/CSS/JavaScript within page templates, so there’s a genuine path from “pure configuration” to “fully custom page” without switching platforms.