Choosing the Right Foundation for Your Dynamics 365 Digital Service

Digital engagement is no longer a "channel strategy." It is the front door to your organisation.

Whether you are a regulator, a government agency, a utility, or a private enterprise, your external portal increasingly determines how customers perceive your brand, how efficiently your operations run, how successfully cases are completed, how well you manage regulatory risk, and how much demand lands in your contact centre.

Today's customers expect secure, intuitive, 24/7 self-service. Microsoft's global customer service research found that around 90% of consumers expect brands to offer an online self-service portal, and a majority prefer self-service over speaking to an agent for routine interactions. McKinsey's analysis of customer experience transformations puts the prize at 20 to 40% lower cost-to-serve, alongside measurable lifts in satisfaction.

There's a catch. Self-service only works when it is well designed.

We have seen this repeatedly across public and private sector programs. An organisation launches a portal to reduce demand on its contact centre. The backend system works. The data flows. The workflows technically execute. Yet users struggle with confusing journeys, clunky UX, unclear validation rules, repeated document uploads, or opaque case tracking. Support calls go up rather than down. Completion rates drop. Trust erodes.

A portal is not a website. It is a digital service.

Why This Conversation Is Specifically About Dynamics 365

For organisations running Dynamics 365 as their core platform or system of record, the portal decision is not about whether to build something new. It is about how to extend an existing business platform outward in a way that protects user experience, governance and long-term value.

At Exco Partners, we specialise in Microsoft-centric transformations, including:

• Dynamics 365 (Sales, Customer Service, Regulatory, Matter and Case Management)
• Dataverse architecture and security design
• Power Platform (Power Apps, Power Automate, Power Pages)
• Azure integration and API-led architectures
• Public sector compliance and regulatory environments

In most engagements, the portal is an extension of Dynamics 365. It enables:

• External case lodgement
• Regulated entity submissions
• Evidence and document management
• Application tracking and status transparency
• Secure role-based access
• Digital engagement, communication and collaboration, often via multi-stage request and response
• Payments
• Multi-stage long-running workflows aligned to backend D365 processes

The architectural question becomes: what platform do we use? In practice that typically reduces to one of two choices. Should the experience layer be platform-native (Power Pages), or product-engineered (open source digital best practice such as React or Next.js)?

Both are valid. Both sit comfortably within a Microsoft ecosystem. But they serve different ambitions.

The Strategic Fork in the Road

When you are running Dynamics 365 as your core business platform, you effectively have two architectural paths for external digital services.

Option A: Stay Platform-Native

Power Pages is Microsoft's low-code portal platform designed to securely expose Dataverse data and Dynamics 365 processes to external users with minimal custom engineering. It provides configurable forms, authentication, security roles and web templates tightly aligned to the Power Platform ecosystem.

Use Power Pages to extend Dataverse externally with low-code configuration, leveraging built-in security models, forms and web templates.

This option is best suited when speed, platform alignment and proportionate complexity are the primary drivers.

Option B: Build a Product-Grade Experience Layer

A React or Next.js portal is a custom-engineered digital experience layer that integrates with Dynamics 365 via APIs, enabling full control over user experience, workflow orchestration and frontend logic. It treats the portal as a long-term digital product rather than a configured platform surface.

Use React or Next.js when you need deep UX design, complex interaction patterns, advanced validation logic or high-performance service delivery.

This option is best suited when the portal experience materially impacts compliance, operational efficiency or customer trust.

The difference is not about technology preference. It is about service ambition, workflow complexity and user expectation.

Why This Decision Matters

Across our projects, in particular in public sector work, we consistently see that:

• Dynamics 365 is highly capable in the backend
• The success or challenges of the service are determined by the frontend experience
• Workflow complexity and experience needs often exceed "simple form submission" patterns
• There is a reluctance to invest appropriatly in the benifits to customer experience

In regulated or compliance-driven environments, portals must:

• Guide users through complex conditional logic
• Reduce submission errors
• Validate against intricate business rules
• Handle structured evidence and document workflows
• Provide lifecycle transparency
• Support accessibility and usability standards

In these contexts, the portal becomes a digital service product rather than merely a web interface. That distinction changes the technology decision and reinforces the necessity to get it right. The intent of this article is to provide a framework for making that decision in a Dynamics 365 context.

The Pros and Cons

Microsoft Power Pages

A low-code portal platform designed to securely expose Dataverse-backed data and workflows to external users.

Where it shines:

• Rapid delivery of standard portal patterns
• Native alignment to Dataverse security and permissions
• Strong fit within Microsoft business applications environments
• Clear licensing constructs (authenticated and anonymous capacity)
• Lower upfront engineering overhead for shallow use cases
• Can be supported by lower skilled engineering teams

Where it becomes constrained:

• Complex multi-stage workflows
• Highly dynamic or conditional forms
• Sophisticated UX patterns
• Advanced interaction logic
• Deep customisation beyond platform norms

Power Pages works exceptionally well when the portal is primarily a secure interface to business data and straightforward process steps.

React / Next.js Custom Portal

A bespoke digital product built with modern digital and web engineering practices.

Where it shines:

• Complex workflow orchestration
• Advanced business rules and conditional logic
• Rich, dynamic, multi-step guided journeys
• Performance and accessibility optimisation
• Deep integration patterns
• Long-term product evolution

This approach is ideal when the portal is a mission-critical service experience, not just a website.

Real-World Context: What We've Seen

The dividing line is almost always workflow complexity and UX ambition.

React or Next.js has been critical when:

• Multi-stage regulatory or compliance processes exist
• Business rules are nuanced and conditional
• Forms are complex, multi-step, branching and high-stakes
• Accessibility and usability materially impact service outcomes

This has been true in environments, where structured journeys, dynamic validation and high completion integrity were essential.

Power Pages is highly effective when:

• The interaction is largely "one-shot"
• Data capture is straightforward
• The process does not require deep branching logic
• The priority is rapid deployment and operational efficiency
• The lifetime support team are less technically skilled

We have effectively implemented these patterns in council-style submissions and standard registrations, where complexity is proportionate and controlled.

The test: the first 20 days of a Power Pages project is easy. The last 20 days is very hard.

A useful field test: the first 20 days of a Power Pages project is easy. The last 20 days is very hard. The opposite is true of bespoke options. The curve inverts because Power Pages rewards staying within platform norms and punishes anything outside them, while a React or Next.js codebase rewards investment in foundational layers that compound over time.

Comparing the Two on the Dimensions That Matter

A Note on Power Pages SPA (and Why It Validates the Argument, 2026 Edit)

In February 2026, Microsoft moved Single-Page Application support in Power Pages to General Availability. Developers can now ship React, Angular or Vue applications to a Power Pages site via the Power Platform CLI, with authentication, Dataverse Web API access and table permissions enforced by the platform. Server Logic followed to GA in April 2026, bringing native server-side JavaScript execution into the same surface.

This is significant, and it should be read carefully. It is Microsoft acknowledging, in product form, that the classic Liquid template and web forms model is not sufficient for serious portal work. The complexity, UX and workflow demands we have been describing in this article have outgrown what low-code configuration can deliver. The platform has had to make room for pro-code.

Power Pages SPA is a useful middle path for some organisations. It softens the worst of the templating constraints while keeping the managed hosting model. For mission-critical, regulated services, however, the residual constraints still matter. SEO is limited because rendering is client-side. Git integration for SPA sites is not yet supported, only compiled artefacts are versioned. Hashed bundles pollute the Dataverse Web Files store across deployments unless you actively manage them, which complicates ALM. The release cadence, hosting model, CDN behaviour and observability stack remain Microsoft's to define. You are still building inside someone else's runtime.

When the experience genuinely is the service, you want the runtime to be yours.

Conclusion: Match the Platform to the Stakes

The Power Pages versus React or Next.js debate is not a technology preference contest. It is a question of service ambition. The right answer depends on what the portal is being asked to do, what happens when it fails, and how long it needs to evolve.

If the portal is a secure interface to business data with controlled complexity and a short evolution horizon, Power Pages is a sensible choice and will get you live quickly. If the portal is the front door to a regulated service, where completion integrity, accessibility, conditional logic and workflow transparency materially impact outcomes, a product-engineered React or Next.js portal is the more honest investment. Microsoft's own move to enable SPAs inside Power Pages confirms the direction of travel: serious portals are pro-code experiences resting on the Dynamics 365 backbone.

That investment becomes a lot easier when the scaffolding is already solved. Our Experience Runtime exists for this reason. It pairs a React and Next.js front end with the Dynamics 365 and Dataverse backbone, handling authentication, API orchestration, document workflows, case lifecycle patterns and the regulator-grade plumbing that programs. Teams get the freedom of pro-code without rebuilding the foundations on every engagement.

Get the decision right at the start and the platform fades into the background. The service does the work. The contact centre quietens down. Get it wrong and you spend the next two years explaining why the portal that was supposed to reduce demand is now creating it.

If you are weighing this decision against a real program, we are happy to walk through it with you. The right answer for your service is rarely the cheapest path or the safest brand bet. It is the one that holds up on day 200, not day 20.