A member self-service portal takes routine admin off the desk: members update their own profile, pay dues, sign up for an event, find a receipt. The harder question is what to build it on. Most advice goes straight to Power Pages, because it is the Microsoft-native option on Dynamics 365, but for a portal thousands of members will log into, how it is licensed matters as much as what it does.
For organisations expecting several thousand members, Azure Static Web Apps is usually the more economical long-term choice. Power Pages tends to win when rapid, low-code delivery matters more than licensing at scale. The rest of this article explains why, and how to tell which case is yours.
Both can do the job, and both sit on the same Dataverse foundation. The choice is therefore rarely decided by features, but by how the cost behaves once the portal is actually used. Power Pages is priced per authenticated user, which makes it predictable at small scale and expensive when many thousands of members log in. An Azure Static Web App is priced on hosting rather than on users, and is usually the cheaper long-term choice for organisations expecting several thousand logins. Power Pages wins when fast low-code delivery matters more than the cost curve, and when you would rather not own the front end yourself. Either route is possible without replacing what you already have.
Same data foundation, two ways to build the portal
Both options sit on Dataverse, the data foundation Dynamics 365 runs on. The member enters information once, and the case worker sees that same information directly in Dynamics 365, with no one retyping it. That is what makes a portal cut admin rather than add to it. The choice is therefore not about the data, but about how the portal is built and licensed, so it belongs in the same conversation as your membership data platform.
Power Pages is Microsoft's low-code portal tool. Authentication, data binding and the access model come built in: web roles set what kind of user someone is, table permissions set exactly which rows and columns they may touch, so a member sees only their own record without you coding it. It is the faster path when the team prefers low-code and the external user count is moderate.
An Azure Static Web Apps portal is a front-end you build yourself, usually a React app for us, served globally and reaching Dataverse through the Dataverse Web API, typically via a small Azure Functions API, with sign-in through Microsoft Entra External ID. For larger global portals that need performance everywhere, a caching layer such as Azure Cache for Redis or Cosmos DB can sit in front of Dataverse. You get full control of the experience, and you build and maintain more.
Cost is the difference that matters most
The figures below are Microsoft's public list prices. See the Power Pages, Static Web Apps and Entra External ID pricing pages. They exclude Dataverse capacity and development. Read them as the shape of the cost, not a quote.
| What you pay for | Power Pages | Azure Static Web App |
|---|---|---|
| Front-end / hosting | Included in the per-user licence | From ~USD 9 per app/month (Standard), 500 GB bandwidth included |
| External users | Authenticated users in packs of 100, or ~USD 4 per authenticated user/month, scales with logins | Entra External ID: first 50,000 monthly active users free, then per MAU |
| API / logic | Built in (low-code) | Azure Functions, billed by consumption (typically modest) |
| Cost as membership grows | Rises with the number of members who log in | Largely flat, independent of member count |
Power Pages bundles everything into a per-user licence. That is simple, and fine while the numbers are small. But it climbs with every member who logs in, so a successful portal becomes its own biggest recurring cost. Even the portal's data API calls count against that licensed capacity, not just page views (documented in Microsoft's Power Pages licensing rules). An Azure Static Web App barely moves: hosting is flat, and sign-in is free below 50,000 monthly active users. A rough monthly comparison makes the gap concrete:
| Members logging in / month | Power Pages (approx.) | Azure Static Web App (approx.) |
|---|---|---|
| 500 | ~USD 1,000/mo | ~USD 20/mo |
| 2 500 | ~USD 5,000/mo | ~USD 25/mo |
| 10 000 | ~USD 7,500/mo and up | ~USD 40/mo |
Illustrative monthly list prices, excluding Dataverse capacity and development. Power Pages bills authenticated users in capacity packs (volume tiers lower the rate at scale). The Azure figures combine Static Web Apps hosting, a small Azure Functions API and Entra External ID (free under 50,000 monthly active users), plus an optional cache tier for large global portals. Even granting generous volume discounts, the two columns do not converge.
"For a member portal, the choice is rarely about features. Both can do the job on the same data. It is about how the cost behaves when the portal succeeds, and how much of the experience you want to own."
Apirut R, Senior Software Engineer at Cartagena, from hands-on member portal delivery
Flexibility, ownership and security
The cost difference has a twin in control. Power Pages gives you a lot for free, but inside its frame. You work the way the tool wants. A Static Web App is a blank canvas: any design, any integration, owned end to end. That freedom is real, and so is the upkeep, since the front-end and API are yours to maintain.
A concrete example is business logic. Power Pages cannot call a Dataverse action, function or Custom API from the page itself; the portal Web API only reads and writes table data. Server-side calculation logic therefore has to live in Dataverse plug-ins, which run on save, or in Power Automate flows. A custom front-end with an Azure Functions API gives you that logic layer directly, on demand.
Security is not a deciding factor on its own. Power Pages enforces access through web roles and table permissions out of the box; on a Static Web App you enforce it in the API layer against Dataverse security, with Entra External ID for sign-in. Both can be equally robust. The question is whether you want that control handed to you or held by you, the same data ownership versus system ownership trade-off that runs through CRM projects.
How to choose without rip-and-replace
Three questions usually settle it, and none require replacing what you already run:
- How many members will log in? The more there are, the more a per-user licence weighs against you, and the more a flat-cost Static Web App pays off.
- How distinctive must the experience be? A close match to your brand and member journey favours a custom front-end; a clean standard portal favours Power Pages.
- How much do you want to own? Capacity to maintain a front-end and API points to Azure; a preference for low-code with less to maintain points to Power Pages.
- Overview: membership systems for Norwegian organisations
Whichever you pick, start narrow: one high-frequency task, profile or sign-ups, built against the data you already have, coexisting with today's systems before you expand. It is the same advisory, non-disruptive path as in change management for CRM.
Pattern: In associations with several thousand members the portal needs are often modest (profile, dues and event sign-ups), yet nearly every member logs in over a year. On a per-user licence that makes the portal its own most expensive line item, which is exactly what tips this profile of organisation towards a flat-cost front-end on Azure.
Conclusion
For most membership organisations the question is not whether Power Pages or Azure Static Web Apps can meet the need, both can. The question is what the portal will cost once it is actually in use, and how much freedom you want to keep developing it further. Those two factors should drive the choice. Whichever way you go, start with one task.
Know the real cost before you build.
We'll calculate the three-year total cost of ownership for both options, using your actual member numbers, expected adoption and licensing model, before you spend a krone on development.
Frequently asked questions about Power Pages vs Azure Static Web Apps
What is the difference between Power Pages and an Azure Static Web App for a member portal?
Both can sit on the same Dataverse and Dynamics 365. The difference is the front-end and the business model. Power Pages is Microsoft's low-code portal tool with built-in sign-in and access control, licensed per external user. A portal on Azure Static Web Apps is a custom front-end that fetches data via the Dataverse Web API, with authentication through Entra External ID, full control over look and behaviour, and a largely fixed running cost regardless of member count.
Which is cheaper to run at member scale?
Usually the Azure Static Web App. Power Pages is priced on authenticated external users, in capacity packs of 100, or around USD 4 per authenticated user per month, so the cost grows with how many members log in. A Static Web App costs from around USD 9 per app per month, authentication via Entra External ID is free for the first 50,000 monthly active users, and you already hold the Dataverse capacity if you are on Dynamics 365. For a portal used by several thousand members the gap becomes noticeable.
Can both connect to Dynamics 365 and Dataverse?
Yes. That is the whole point. Both write to and read from the same Dataverse store that Dynamics 365 uses, so the member writes once and the case worker sees the same record with no step in between. Power Pages connects natively; a Static Web App connects via the Dataverse Web API, usually through a small API layer in Azure Functions.
Is a custom portal on Azure Static Web Apps less secure?
Not in itself, but the responsibility moves. Power Pages gives you access control ready-made with web roles and table permissions. On a Static Web App, access is enforced in the API layer against Dataverse security, with sign-in through Entra External ID. That gives more control, but you design and own the model yourself. Both can be equally safe. The difference is how much you build versus inherit.
Can I put business or calculation logic in Power Pages?
Only to a limited degree. The portals Web API supports reading and writing table data, not calling actions, functions or a Custom API from the page (Microsoft's own documentation confirms this). Server-side calculation logic has to live in Dataverse plug-ins, which run on save, or in Power Automate flows. If you need a freely callable logic layer, that points to a custom front-end on Azure Static Web Apps with an Azure Functions API.
Do we have to replace anything to build either one?
No. A portal is a layer on top of the data you already have, whichever front-end you choose. Both can start with one bounded need, say profile and sign-ups, against today's Dataverse, and coexist with the existing member register and finance system. It is a coexistence model, not a replacement. If the choice sits further upstream, between keeping the membership system or moving to a platform, we take that up in our article on membership system or CRM platform.
What does Cartagena recommend?
For member portals meant for many members, we usually recommend a custom front-end on Azure Static Web Apps over Dynamics 365 and Dataverse. It gives more flexibility in the experience and a lower, more predictable running cost, because it is not priced per logged-in member. Power Pages is a good choice when you want to start fast with low-code and the external user count is moderate. The choice should follow member scale, experience ambition and how much you want to own.
Sources
- Microsoft Learn: Power Platform licensing FAQs
- Microsoft Azure: Pricing for Azure Static Web Apps
- Microsoft Learn: What is Microsoft Dataverse?
- Microsoft Learn: Use the Microsoft Dataverse Web API
Sources retrieved and checked 30 August 2026.