Power Apps Portals history and rebranding to Power Pages

By Emil Björk · Microsoft business apps consultant, Gothenburg

From ADXStudio to Dynamics 365 Portals to Power Apps Portals to Power Pages — the product genealogy and what the rebranding means for customers.

Reviewed May 20263 min read · 611 wordsPublished
On this page (8)

The product now called Power Pages has had several names over the past decade. Older documentation, older training materials, and the institutional vocabulary of long-time partners all reflect prior names. Understanding the lineage helps when reading legacy content and explaining the product's trajectory.

ADXStudio (2002–2015)

The origin:

  • Canadian company building portals for Dynamics CRM customers.
  • Open-source-ish base; commercial product.
  • Liquid templating, table permissions, web roles — concepts still alive today.
  • Acquired by Microsoft in 2015.

Dynamics 365 Portals (2016–2018)

First Microsoft incarnation:

  • ADXStudio rebadged.
  • Integrated with Dynamics 365.
  • Available as add-on to D365 customer subscriptions.

Power Apps Portals (2019–2022)

Power Platform alignment:

  • Renamed Power Apps Portals when Microsoft re-aligned the broader Dataverse / Power Platform story.
  • Same product, slight feature evolution.
  • Sold as Power Apps capacity-based licensing.

Power Pages (2022–)

Current branding:

  • Renamed Power Pages.
  • Modernised authoring experience (Design Studio).
  • AI-assisted page creation (Copilot).
  • Stronger focus on low-code makers vs developer customisation.

The product underneath has continuity; the surface has been progressively modernised.

Concepts preserved from ADXStudio.

  • Liquid templating language — used throughout.
  • Entity / table permissions — record-level access control.
  • Web roles — group users for permissioning.
  • Web templates — reusable HTML/Liquid templates.
  • Entity forms / entity lists — Dataverse data rendering.
  • Web files — static content (images, CSS).

A developer familiar with ADXStudio finds Power Pages's underlying model immediately familiar.

Modernisation in Power Pages.

  • Design Studio — visual page builder.
  • Themes — modern theming.
  • Copilot — AI-suggested pages, content, code.
  • Pages tied to Dataverse Pages mode — newer pattern.
  • Improved performance — CDN-based content delivery.

The maker experience is faster and more modern than ADX-era.

Two authoring modes.

  • Design Studio — visual, drag-and-drop. For makers.
  • Portal Management app — table-level editing. For developers/admins.

Most makers use Design Studio; deep customisation uses Portal Management.

Authentication providers

Evolved over time:

  • Initially Microsoft-only.
  • Added Azure AD, social providers (Google, Facebook).
  • Now: Entra External ID is the canonical B2C identity provider; supports SAML, OIDC, local accounts.

Use cases.

  • Customer self-service portals — case submission, knowledge browsing.
  • Partner portals — partner enablement.
  • Supplier portals — vendor self-service for F&O.
  • Community forums.
  • Public-facing websites — though typically not pure Power Pages; CMS for content.
  • Industry-specific portals — healthcare patient, banking customer.

Licensing evolution.

  • Pay-per-user — per authenticated user / login.
  • Pay-per-login — per session.
  • Capacity-based — purchased capacity tiers.

Current: capacity-based, with anonymous and authenticated session tiers.

Comparison with custom-built portals.

  • Power Pages — fast to build; Dataverse-integrated; managed by Microsoft.
  • Custom React + Dataverse API — flexibility; more dev work.
  • SharePoint — for intranet-style scenarios.

Power Pages wins for Dataverse-centric portals at moderate complexity; custom builds win for highly bespoke UX.

Migration considerations

From older portal versions to Power Pages:

  • Core data and configuration migrate.
  • Custom Liquid templates carry over.
  • Visual styling may need refresh.
  • Authentication providers updated.

Microsoft provides migration guidance per legacy version.

Common Liquid patterns.

{% assign cases = entities.incident | where: 'customerid', user.contactid %}
{% for case in cases %}
  <div>{{ case.title }} — {{ case.statecode }}</div>
{% endfor %}

Liquid is the templating language for dynamic content.

Power Pages Pro Code

For developers extending beyond no-code:

  • VS Code with Power Pages extension.
  • Edit Liquid, JavaScript, CSS in code.
  • Deploy via Power Platform CLI.

This is the developer surface; makers use Design Studio.

Common pitfalls during transition.

  • Sticking with old terminology. Customers say "portal"; product team says "page" — confusion.
  • Migrating without redesign. Legacy visual style brought forward; outdated UX.
  • Authentication migration overlooked. Old social providers deprecated; users locked out.
  • Performance regression. Lift-and-shift without optimisation; pages slow.

Strategic positioning

Power Pages is the strategic direction for Dynamics 365 customer-facing portals. Power Apps Portals customers should plan to embrace the new branding and capabilities; older Dynamics 365 Portals or ADX customers face a more substantial modernisation. For new portal initiatives, Power Pages is the natural choice — integrated, supported, evolving.

The product underneath has nearly two decades of evolution; the latest branding is the modernised face. Understanding both the lineage and the trajectory helps customers and developers plan appropriately.

Further reading

Related guides

Browse every guide in Power Platform or just Power Apps.

Was this helpful?

Signals which guides land and which need work. No account, no comment box — corrections go through the contact page.

Spot something wrong or want a topic covered? Send a correction or a topic request — both are welcome.