Power Apps Portals history and rebranding to Power Pages
From ADXStudio to Dynamics 365 Portals to Power Apps Portals to Power Pages — the product genealogy and what the rebranding means for customers.
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.
Related guides
- PCF controls in Power AppsWhat Power Apps Component Framework (PCF) controls are, when to use them, and the developer toolchain to build, package, and deploy.
- Power Apps Component Framework (PCF) control developmentHow to build custom controls with the Power Apps Component Framework — the dev environment, lifecycle, manifest, packaging, and the common pitfalls for production PCFs.
- Power Apps modern controlsHow the modern control set in canvas apps differs from classic controls — Fluent UI styling, accessibility defaults, theming, and migration considerations.
- Power Apps monitoring and Application InsightsHow to monitor Power Apps in production — App Monitor, Application Insights integration, and the operational patterns for performance and error tracking.
- Power Apps performance tuningHow to make Power Apps canvas and model-driven apps fast — startup time, screen render, data fetching, formula optimisation, and the patterns that matter.