Customer Self-Service Portal on Dynamics 365: Power Pages or a Custom Front End?

What are the three ways to give external users access to Dynamics 365 data?

Every customer or partner portal on the Microsoft stack ends up as one of three shapes. They differ in who holds the identity, how Microsoft licenses the access, how much of the interface you design yourself and who has to keep it running. The table is the short version; the sections below explain each row.

When are Entra B2B guest accounts enough?

Microsoft Entra B2B lets you invite a person from another organization into your tenant as a guest. They sign in with their own work account, you add them to the right Dataverse environment and security role, and they use the same model-driven or canvas apps your staff use. For a distributor with a few people who need your order or claims app, this is the quickest route, because there is no second site to design, secure or host.

The limits are licensing and administration. A guest using a Power Apps app still needs a licence that carries the right Power Apps use rights, whether it is assigned in your tenant or, in some cases, held through the home tenant; Microsoft documents which combinations qualify, and the rules have changed over time, so confirm them against current Microsoft guidance before you plan the route. Guests also sit in your directory, so they fall under your Conditional Access policies, your joiner and leaver process and your access reviews. That is appropriate for a few trusted partner users and unworkable for a customer base.

How does Power Pages handle external identity, table permissions and web roles?

A Power Pages site authenticates external people against an identity provider: Microsoft Entra External ID (the successor to Azure AD B2C for new customers), an OpenID Connect or SAML 2.0 provider you already run, or social and Microsoft accounts. Each signed-in person is linked to a Contact row in Dataverse, and that link is what security hangs on. Local username and password sign-in still exists, but Microsoft steers new sites towards an external provider, and so do we.

Record access is decided by web roles and table permissions. A web role (for example authenticated customer, partner administrator) is assigned to contacts, and table permissions attached to that role grant create, read, write, delete, append and append-to on a table within a scope: global, contact (records linked to the signed-in contact), account (records linked to the contact's parent account), parent (records reached through a relationship from a permitted record) or self. That is how you restrict a portal user to their own cases, or a partner administrator to their own company's orders. The same permissions govern lists, forms, Liquid queries and the portal Web API, which has to be switched on per table and per column. Designing and reviewing these rules is the core of the build described in the Power Pages section of our Power Platform service.

How does Power Pages licensing scale with the number of external users?

Power Pages is not licensed per named external user the way internal Power Apps users are. It is licensed by capacity per website per month: authenticated user capacity, counted as unique people who sign in to that site in the month, and anonymous user capacity, counted as unique visitors who use the site without signing in. You buy that capacity as prepaid subscriptions or pay as you go through an Azure subscription. Internal users who already hold qualifying Power Apps or Dynamics 365 licences can generally use a site without consuming external capacity. We do not quote prices here, and the definitions, qualifying licences and minimums are revised by Microsoft, so check the current Power Platform licensing guide or your licensing partner before you budget.

• What scales well: a large registered base where only part of it signs in each month, because you pay for monthly active people, not for everyone who ever registered.
• What surprises teams: a renewal, enrolment or tax deadline that brings most of the base in the same month, and public pages that count towards anonymous capacity.
• What to model before you choose: expected monthly unique sign-ins per site, anonymous traffic on pages that read Dataverse, and whether you will run one site or several, since capacity is per site.
• For the procurement side of any Microsoft licensing decision, our Dynamics 365 licensing procurement guide covers how to get a written answer rather than an assumption.

Does a custom front end on the Dataverse Web API avoid Microsoft licensing?

No, and this is the most expensive misunderstanding in portal projects. A React or Next.js site calling the Dataverse Web API through an application user (a service principal) is technically straightforward, and the application user itself does not need a Power Apps licence. But Microsoft licensing looks at the people whose work reaches Dataverse, not at the account the code signs in with. Pooling many external users behind one service account or middle tier is what the licensing guide calls multiplexing, and it does not reduce the licences those users would otherwise need. For external audiences, Power Pages capacity is the channel Microsoft designed for this.

So a custom front end over Dataverse can be the right technical choice, for experience or performance reasons, but treat the licensing as unresolved until your Microsoft licensing partner has confirmed the model in writing for your exact scenario. The route that genuinely removes Microsoft licensing is a custom front end over your own database, for example PostgreSQL behind a Node.js or .NET API, with the CRM data either living there or synchronized in only the subset the portal needs. That is the custom CRM route, and it moves hosting, security and support onto you or your delivery partner.

How much of the portal is standard forms, and how much is bespoke experience?

This is the question that usually settles the choice once licensing is understood. Walk through the screens the portal needs and mark each one as either a form, list or detail view over a table, or an experience that behaves like an application: multi-step configurators, live pricing or availability, maps, drag and drop, offline use, heavy client-side interaction.

• Mostly forms, lists and status views: Power Pages delivers these from configuration, and a few awkward screens can be handled with Liquid, the portal Web API or PCF controls embedded in portal forms.
• A mix, with a small number of genuinely bespoke journeys: still usually Power Pages, with the bespoke screens built in code. Microsoft has also been adding support for hosting single-page applications built in frameworks such as React on Power Pages, which keeps the Power Pages security and licensing model; check its current availability before you depend on it.
• Bespoke on most screens, a brand-led consumer experience, or strict page-load targets under peak load: a custom front end, where you control rendering, caching and the whole user journey.

Where does the data live, and what does that mean for data residency?

Residency depends on the route, and the identity store is often the part people forget.

Who reviews external access, and how?

Every portal needs an answer to "who still has access and should they?", and each route answers it differently.

• Guest accounts: Microsoft Entra access reviews can ask sponsors to recertify guests on a schedule and remove those not confirmed, which needs the appropriate Microsoft Entra ID Governance licensing. Without it, reviewing guests is a manual job someone must own.
• Power Pages: access is the combination of the contact record, its web roles and the table permissions attached to them. Review web role assignments per account, deactivate contacts when a customer relationship ends, expire invitations, and re-test table permissions whenever the data model changes, because one table permission with the wrong scope exposes every row in that table.
• Custom front end: you design the review. Build role assignment, audit logging and an administration screen into the first release rather than relying on database queries when an auditor asks.

Who maintains the portal after go live?

Power Pages is maintained by Power Platform people: managed solutions moved through pipelines, Microsoft platform updates tested as they arrive, table permissions reviewed as the model changes. If you already run Dynamics 365 Customer Service or other Dataverse apps, the same team can own the portal, and the case process customers see is the same one agents work.

A custom front end is maintained by software engineers: framework and dependency upgrades, security patches, hosting, monitoring, identity integration and API changes on the Dataverse side if it reads from there. That is a permanent line in the budget, not a project cost. If the answer to "who owns this in three years?" is unclear, the custom route is the riskier one, however good the first release looks.

What goes wrong when teams pick the wrong route?

The failures we are asked to fix follow a small number of patterns.

• Guest accounts for customers: the directory fills with external identities nobody reviews, every guest needs licensing that was never budgeted, and customers are asked to sign in to what looks like an internal Microsoft app.
• Power Pages for a product-grade experience: months of fighting the platform for screens it was not designed to render, followed by a rebuild in code.
• Power Pages with loosely scoped table permissions: global scope used to make a list "just work", exposing other customers' records. It is the most serious portal defect and the easiest to miss in testing with a single test account.
• Power Pages without a volume model: capacity bought for the average month, then a deadline month that far exceeds it.
• A custom front end over Dataverse on the assumption that a service account removes licensing: a compliance exposure discovered at a Microsoft audit or renewal rather than at design time.
• A custom front end with no owner: a well-built first release that nobody patches, whose framework version falls out of support.

How does Solzet recommend a route?

We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both.

For portals that means we start with the audience size and growth, the list of screens and how many are standard, the identity requirements, the residency constraints and the team that will own the result, then recommend guest accounts, Power Pages or a custom front end. Our senior consultants and full-stack developers build Power Pages portals on the same Dataverse as the CRM, and build custom front ends and custom CRM systems on React, Node.js, PostgreSQL and .NET when Microsoft licensing does not fit. With 8+ years of CRM delivery, we would rather settle the route in discovery than rebuild a portal later.