A Practical Look at the Dynamics 365 Customer Portal

Gartner surveyed 5,728 customers and found that 73% of them use self-service somewhere in their service journey, while only 14% of issues get fully resolved there. For issues customers themselves described as very simple, the figure was 36%.

Read those two numbers together, and you get the most useful thing anyone can tell you before you scope a Dynamics 365 customer portal. Getting people to use it is not the hard part. Getting them to finish is.

Most portal business cases are written as though usage and resolution are the same measurement. They are not, and the distance between them is where the first year of running a portal actually goes. What follows is what that year consists of, in the specific terms of a portal built on Dataverse.

The two ways self-service fails, translated into configuration

Gartner asked customers who started in self-service and did not finish what went wrong. Two answers dominated: 45% said the company did not understand what they were trying to do, and 43% could not find content relevant to their issue.

Both of those sound like content problems. In a Dynamics portal, only one of them is.

The findability half is genuinely about content. Knowledge articles written in internal vocabulary, categories that mirror your org chart rather than the customer’s problem, search that returns the article you wrote instead of the one they needed.

The other half is usually not a content problem at all. When a customer says the company did not understand what they were trying to do, what often happened on a Dynamics portal is that the page loaded and returned nothing. They were looking at the right screen with the wrong records behind it. That is a permission model outcome, and it is the single largest source of avoidable portal contacts in year one.

Where “I can’t see my invoice” comes from

Access to Dataverse records is closed by default on a Power Pages site. Forms, lists, Liquid, and the Portals Web API all return nothing until a table permission opens a path, and a table permission does nothing at all until it is associated with at least one web role. That last rule catches people. You can build a correct permission, save it, and have it apply to no one.

The access types are where the design decision lives. Global returns all records in the table. Contact returns records related to the signed-in user. Account returns records related to the signed-in user’s account. Self returns only the user’s own contact record. There is also a Custom access type in preview, available on sites enabled for enhanced authorization, which filters by a FetchXML condition, and a Parent type that only appears in the Portal Management app.

Almost every portal ticket that starts with “I can’t see” resolves to a mismatch between Account access and the actual shape of the customer’s data. Account access resolves through the relationship between the contact and the account. If a customer’s records are attached to a second account record created three years ago by a different sales rep, the portal is behaving correctly and the customer is still staring at an empty list.

The practical consequence is that the portal publishes your CRM data hygiene to the people least equipped to interpret it. Run the account and contact relationships before go-live, not after the tickets start.

Nobody owns the part where access ends

Portal users are contact records in Dataverse. Access is granted either by adding a username on the Web Authentication tab of the contact’s form and setting a password, or by sending an invitation, which is the better path at volume. An invitation carries a code and an optional expiry date, and on redemption it can attach the contact to an account, assign one or more web roles, and run a workflow. Redemption writes an Invite Redemption activity onto both records.

That is a well-built front door. Most implementations then discover they never built the back one.

When someone leaves a customer’s company, nothing in the CRM knows to close their portal access, because the event happens at an organization you do not administer. Nobody tells you. The contact record sits there with a username, a password, and a web role that still resolves to that account’s orders and invoices.

This is worth deciding before launch rather than during an audit. The two workable answers are an identity provider that already handles the customer’s own joiner and leaver process, which is one of the arguments for moving off local authentication, or a periodic access review that the account owner signs off on. Both are unglamorous. Both take about an hour to define and roughly forever to retrofit.

Local authentication is also the path Microsoft is steering away from. The guidance is to use an external identity provider and deprecate the local one, and there is a site setting for exactly that migration. Anyone still planning around Azure AD B2C should also know it stopped being available to new customers on May 1, 2025, and that B2C P2 was discontinued for all customers on March 15, 2026. Existing tenants are supported until at least May 2030, which is time to plan and not time to ignore.

You will spend most of year one unable to see what is happening

Here is the awkward one. Configurable site analytics and server logging for Power Pages, covering page views, form interactions, client-side activity, server-side error detection, and access logs, is scheduled for public preview in September 2026. It does not yet carry a general availability date.

Until that lands and matures, the instrument most teams use to judge a portal is case volume, which is the wrong instrument. Case volume moves for a dozen reasons that have nothing to do with the portal, and it cannot distinguish a customer who resolved their question from a customer who gave up quietly. Gartner’s 14% exists precisely because giving up is invisible.

Two things partly fill the gap in the meantime. Instrument the portal yourself for the handful of events you actually care about, chiefly search terms that return nothing and forms that get opened and abandoned. And measure the contact side rather than the portal side: how many inbound contacts are people asking for something the portal already shows them. That number is a direct readout of findability and permission configuration, and you can collect it with a case subject field and no new tooling.

What the bill actually scales with

Power Pages authenticated access is sold as a capacity pack: $200 per month for 100 users, for one website, on a calendar month basis, paid yearly. Anonymous access is $75 per month per 500 users, again per site. Volume tiers exist well up the curve, at 10,000 and 100,000 users.

Three details in that sentence do more damage to budgets than the headline rate.

Capacity is per website. A customer portal and a partner portal are two sites and two sets of packs, even for the same people. Capacity is per calendar month and unused capacity does not carry over, so a business with a quarterly billing cycle pays for its peak month every month or absorbs the overage in the months that matter. And capacity counts users who authenticate, which means the growth driver is your customer’s headcount and login habits, not your own.

Model the busiest month against your actual contact list, not the average against your account list. That single correction accounts for most of the gap between a portal business case and a portal invoice.

Your portal is on someone else’s release calendar

One item on the current roadmap is worth putting in a planning document now. The unification of Power Pages authorization, which merges web roles into Dataverse security roles and site users into system users, entered public preview on July 8, 2026 and is scheduled for general availability in November 2026.

If you are configuring a permission model this year, you are configuring it against a model that is being replaced. That is not a reason to wait. It is a reason to document why each permission exists rather than only what it does, because the rationale is what survives a migration and the configuration is not.

Where portal products change the shape of this

Some of the year-one work above is a product decision rather than a project decision. Third-party portal platforms that sync to Dataverse carry their own permission layer, their own user management, and their own pricing model, which moves some of these problems and removes others.

The pricing one is the clearest contrast. CRMJetty publishes a flat rate of $399 per month for up to 500 portal users and states plainly that there are no per-login charges, capacity packs, or overage fees, at the same rate across Dynamics 365, Salesforce, SugarCRM, and SuiteCRM. Whether that is cheaper depends entirely on your authenticated user count, and the crossover arrives sooner than most teams expect.

What it does not change is any of the rest of it. Whichever platform renders the pages, someone still has to decide which customer sees which record, notice when a customer’s staff member leaves, keep the content current, and find a way to measure whether people are finishing.

The first ninety days

Audit account and contact relationships before you configure a single table permission. Decide who reviews portal access and how often, and write it down. Instrument search terms that return nothing. Count the inbound contacts that ask for something already on the portal, and treat that number as the real score. Model your peak month.

None of that is portal construction, and all of it decides whether the portal ends up in the 73% or the 14%.