Portal customization is usually presented to a business as a scope question. How many pages, which entities, what does it look like, when does it go live? Those questions produce a build estimate, the estimate gets approved, and the project proceeds.
The estimate is rarely where the money goes.
Portal customization is more accurately a recurring-cost and ownership question wearing a project’s clothing. What you decide during customization determines your external-user licensing exposure, your annual maintenance obligation, and whether anyone in the organization can change the portal in eighteen months without a vendor engagement. Those consequences outlast the build by years, and they are seldom the subject of the approval conversation.
This guide covers the decisions that actually drive portal cost for a Dynamics 365 Customer Portal organization in 2026, in the order a business should confront them.
What “customization” means now, and why the answer moved
The technical bar for producing a portal dropped sharply over the past two years. Power Pages reached general availability with AI-assisted site building, and agentic tooling became available across public regions in May 2026. Independent portal products moved in the same direction with no-code builders and configurable entity layouts.
The effect on planning is genuinely significant, but not in the way vendors present it. Building pages got cheaper. Deciding what belongs on them did not.
Every portal requires the business to answer questions that no builder can answer for it. Which customer segment sees which contract. Whether a distributor can view pricing for products they do not carry. Who approves a new portal role. What happens when someone’s account is disputed, and their portal access should probably pause. These are policy decisions; they take weeks of organizational time, and they were always the long pole in the project. Faster page construction has made that more visible, not less.
Treat any timeline built on build speed alone with suspicion. The critical path runs through your own decision-making.
The three cost lines nobody budgets
Portal business cases tend to include implementation, licensing, and a contingency. Three real costs sit outside that structure.
The second year
Year one costs are visible because someone is invoicing for them. Year two costs are the ones that arrive quietly: a change to the product catalog that requires updating the portal layout, a new customer tier that needs its own permission set, a workflow adjustment when the support process changes.
None of these are large individually. Collectively, they establish whether your portal is a living system or a frozen one. Budget an explicit annual change allowance, even a modest one, and name who spends it. Portals without that allowance do not stay current, they stay unchanged until they are unusable and then get replaced at full cost.
The access review
If the portal exposes contracts, invoices, pricing, or personal data, someone will eventually need to demonstrate who could see what and when. That review is inexpensive if the portal’s role model is documented and coherent. It is expensive if permissions accumulated case by case over two years with no record of why.
The cost here is entirely determined by decisions made during customization. A clean role structure defined up front costs a few extra planning sessions. Reconstructing one after the fact costs considerably more, and it tends to be requested on someone else’s timeline.
The integration surface
Portals rarely stay standalone. Payment collection, document storage, e-signature, and analytics all arrive as follow-on requests within the first year, because once customers are transacting in a portal, the obvious next question is what else they can finish there.
Whether those are configuration changes or development projects depends on choices you make now. Ask during evaluation which integrations are supported out of the box and which require custom work, then compare that list against your roadmap rather than against your launch scope.
Scope from the user journey, not the feature list
The most reliable predictor of a portal that gets used is that it was scoped around a small number of complete journeys rather than a broad set of partial features.
Feature-list scoping produces portals where a customer can view an invoice but not pay it, or submit a case but not see its history. Each feature is present. No task can be finished. Adoption stalls, and the organization concludes that customers did not want a portal.
Journey scoping asks a different question: what are the three things an external user most often contacts us to do, and can they complete each one end to end without help? Three complete journeys beat fifteen partial ones, and they leave a much clearer picture of what to build next.
This also gives you a defensible way to cut scope under pressure. Removing an entire journey is a decision the business can reason about. Removing half the steps in every journey is how portals fail quietly.
Build versus configure, in business terms
The technical version of this debate is about capability. The business version is about who is available to change the portal after the people who built it have moved on.
| Decision input | Points toward configuration | Points toward custom development |
|---|---|---|
| In-house Dynamics or web development capacity | Limited or fully committed | Established team with release process |
| Frequency of expected change | Regular, driven by the business | Rare, stable requirements |
| Uniqueness of the process | Recognizable portal patterns | Genuinely unusual workflow |
| Tolerance for vendor dependency | Acceptable | Low, control is a priority |
| Who must be able to make changes | Business users or admins | Developers are available anyway |
The row that decides it most often is the last one. If the answer is that a business user needs to adjust the portal without raising a ticket, that requirement rules out a significant amount of custom development regardless of how the other rows score.
A note on mixed approaches, which is what most organizations end up with. That is a reasonable outcome, but keep an inventory of every custom element and what it depends on. The organizations that struggle at upgrade time are not the ones with custom code, they are the ones who no longer know where it is.
How portal pricing models behave as you grow
This is the section most likely to change a business decision, because the models do not differ by a percentage, they differ in shape.
Capacity-pack pricing. Power Pages sells authenticated user capacity in packs of 100 per website per month, assigned at environment level, with unused capacity expiring rather than carrying forward. Cost moves in steps: users 101 through 200 cost the same as user 101 alone. Anonymous access is sold separately in its own blocks.
Two planning consequences follow. First, your cost is set by peak monthly authenticated users, not average, so a seasonal audience pays for its peak all year unless you actively manage packs. Second, sitting just above a pack boundary is the worst place to be, which makes accurate active-user forecasting worth real effort before launch.
Per-user and per-login pricing. Common in the wider portal market, this ties cost directly to audience size or activity. Predictable for a stable audience, and difficult to forecast for a growing or spiky one.
Flat-fee tier pricing. Independent portal vendors, including those offering customer portals for Dynamics 365, commonly price against a user-base tier with full feature access rather than metering activity. Cost becomes a fixed line item within a tier, which finance teams generally prefer, though the tier boundaries create their own step changes.
The recommendation is the same in all three cases and it is not about which model is cheapest. Model your actual expected active users at launch, at twelve months, and at thirty-six months, then price all three shapes against those numbers. The cheapest model at launch is frequently not the cheapest at scale, and portal contracts are not renegotiated casually.
Who owns the portal after go-live
The question most likely to be skipped, and the one that determines whether the investment holds its value.
A portal needs a named owner with three specific authorities: approving changes to the role and permission model, prioritizing the annual change allowance, and deciding when a customization is retired. Not a committee, not a team name, a person.
Portals without a named owner follow a predictable path. Requests accumulate with no one to sequence them. Permission exceptions get granted individually because no one owns the model. Within about two quarters the portal reflects a set of decisions nobody made deliberately, and the organization starts describing it as legacy.
Decide this before launch, and write down what the owner is accountable for. It costs nothing and it is the single highest-return governance decision in the project.
A 2026 planning checklist
- Name the three complete journeys the portal must support end to end at launch.
- Forecast active external users at launch, twelve months, and thirty-six months, and understand that active is not the same as your contact record count.
- Price at least two licensing shapes against those forecasts before choosing a platform.
- Define the role and permission model before any page design work begins.
- List your expected integrations for the next eighteen months and confirm which are configuration rather than development.
- Set an annual change allowance and name who allocates it.
- Name the portal owner and document their authorities.
- Keep a customization inventory from day one, including what each item depends on.
The bottom line
Portal customization decisions look technical and are mostly financial and organizational. The layout choices are reversible. The licensing model, the permission architecture, and the ownership structure are not, or at least not cheaply.
The Dynamics 365 organizations that get durable value from a portal are not the ones that customized the most or the least. They are the ones that forecast their real user numbers honestly, scoped around complete journeys instead of feature counts, and named someone accountable for the portal before it went live.
