How to Build a Customer Portal Connected to Business Central

If you run Dynamics 365 Business Central in UK manufacturing or wholesale distribution, this scenario is familiar. A customer calls at 11am. “Where’s my order?” Your salesperson opens BC, navigates Sales Orders, finds the record, checks the Posted Shipment, opens the warehouse dispatch note, and finally reads the carrier tracking link. Four minutes, three screens. They relay the answer. Customer hangs up. Then the next call comes in.

For a business processing 200 orders a day, that pattern repeats dozens of times. Each interruption costs somewhere between two and four minutes of a skilled salesperson’s time. Over a month, that adds up to days, not hours. And it is entirely unnecessary.

Business Central already stores every piece of data the customer wants. The problem is access. Your customers cannot reach into your ERP, and your staff are stuck being a human API between the database and the phone.

This article walks through exactly how to build a branded customer self-service portal on top of Dynamics 365 Business Central. We cover the architecture, the API surface you need, the three major approaches (ISV add-ons, Power Pages, custom-built), the security model, and a realistic process and budget.

The real cost of no customer portal

Before we talk about technology, let us quantify the problem. A distributor with 15 inside salespeople processing 40 order-status calls per day each is burning roughly 3.2 hours of productive time per person per week on information retrieval. That is 48 hours a week across the team. At a blended cost of £35 per hour, that is £1,680 per week — over £87,000 per year — spent on work that a portal could do for free.

That figure excludes the secondary costs: customers waiting on hold, salespeople who cannot close deals because they are answering queries, admin staff forwarding emails with invoice PDFs attached. A customer portal does not just improve customer service. It restructures how your team spends its time.

What a Business Central customer portal actually is

A customer portal is a web application that sits alongside your ERP and exposes a subset of Business Central data to your customers through a branded, customer-friendly interface. The portal does not replace BC. It does not modify BC. It reads from and writes to BC through its REST API.

The customer logs in, sees their orders, their invoices, their account balance, and their stock availability. They download PDF documents. They reorder items they bought last month. They submit queries. All without picking up the phone and without any member of your staff logging into BC on their behalf.

Your ERP stays exactly as it is. Data lives in Business Central. The portal is an interface layer.

Architecture overview

A production customer portal uses four logical layers. Here is the architecture:

The critical design principle: the portal backend is the only component that talks to Business Central directly. The customer’s browser never sees BC credentials, never makes direct API calls to your ERP. The backend transforms BC’s API responses into the data your customer needs, scoped to their account only.

Business Central API coverage for customer portals

Dynamics 365 Business Central exposes a comprehensive REST API v2.0. Here are the endpoints that matter for a customer portal, along with the operations each supports:

Each endpoint supports OData query parameters ($filter, $select, $top, $skip), which means the portal backend can request only the data relevant to the authenticated customer. No need to pull the full sales order table and filter on the application side.

One important detail: Business Central’s API does not expose every field that appears in the BC client UI. Some fields (certain warehouse entry details, for example) require either a custom API page extension or a bespoke API endpoint built in AL. During the discovery phase of any portal project, we map precisely which fields are available natively and which require extension. In our experience, 85-90% of customer portal use cases are covered by the standard API surface. The remainder typically require two to five custom API extensions in AL — straightforward for any competent BC partner.

Three approaches compared

There are three routes to a customer portal over Business Central. Each has trade-offs. Here is the honest assessment.

Option A: ISV add-ons (Simova, Dynamics eShop, etc.)

Several Microsoft partners sell customer portal solutions built on top of BC. Simova Customer Portal and Dynamics eShop are two of the more common ones. These are pre-built applications that sit on top of BC and expose a customer-facing web interface. They work well for standard use cases out of the box.

The limitations emerge when you need something that does not fit the template. Pricing different from the ISV’s defaults. A custom field on the order page. A specific workflow for proof-of-delivery capture. Non-standard branding. Integration with your existing website SSO.

Option B: Microsoft Power Pages

Power Pages is Microsoft’s low-code platform for building external-facing websites. It integrates directly with Dataverse and, through the Business Central connector, can surface BC data. It is a genuine option for organisations already committed to the Power Platform ecosystem.

Power Pages works well for simple forms and data display. It struggles with complex transactional flows (placing orders, real-time stock checks with reservation logic) and can become expensive at scale. Power Pages licensing is per-user per-month, and the cost escalates as your customer base grows.

Option C: Custom-built portal (Sysgraft’s approach)

A custom-built portal uses a modern web framework (Next.js, Remix, or similar) to build a UI layer that calls the BC API through a backend-for-frontend (BFF) pattern. The portal is yours — your brand, your workflows, your data model. No template constraints. No per-customer license fees.

The trade-off is upfront investment. A custom portal costs more to build than deploying an ISV add-on. The total cost of ownership over three years is typically lower, because there are no per-customer license fees and you own the code.

Our view: ISV add-ons are a reasonable starting point if your requirements are entirely standard and you do not anticipate growth in complexity. Power Pages makes sense if you are already deep in the Power Platform and your portal requirements are read-only and form-based. Custom-built portals work best when you need full control, have specific workflows, or want to avoid per-customer licensing costs as your customer base scales beyond 100-200 users.

Authentication and security

Security is the most common concern when connecting a customer-facing application to your ERP. Here is how it works in practice.

The portal uses OAuth 2.0 with the authorisation code flow + PKCE for customer authentication. Customers authenticate through your own identity provider or through their existing Microsoft Entra ID credentials. The portal never sees a password. Tokens are short-lived (60 minutes by default) and refreshed transparently.

The connection between the portal backend and Business Central uses the OAuth 2.0 client credentials grant. The backend authenticates as a service principal registered in your Microsoft Entra ID tenant. This is a system-to-system integration. No user credentials are involved. The service principal has scoped permissions to read and write only the API endpoints the portal needs.

Data scoping is enforced at the backend layer, not at the BC API level. The portal backend receives the customer identifier from the authentication token, then queries Business Central with $filter=customerNumber eq 'XXX'. Customer A can never see Customer B’s data because the backend never requests it. This is a simple, auditable, and reliable pattern.

Additional security measures:

• Rate limiting per customer account prevents any single customer from overwhelming the BC API (and your ERP’s performance).
• Request logging captures every API call the portal makes to BC, with customer ID, endpoint, and timestamp. Full audit trail for compliance.
• TLS 1.2+ for all connections. The portal enforces HTTPS exclusively. HTTP requests are redirected or rejected.
• Web application firewall at the load balancer layer blocks common attack patterns (SQL injection, XSS, path traversal).
• No BC credentials are ever exposed to the browser. The frontend communicates only with the portal backend, never directly with BC.

Build process: from discovery to live

We have shipped enough customer portals over BC to have a repeatable process. It divides into three phases.

Phase 1: Discovery sprint (3–5 days)

A fixed-fee sprint where we audit your BC instance, map the API surface, identify the fields you need, and produce a detailed functional specification. This is not a theoretical exercise — we connect to your BC API, pull real data, and validate what is available natively versus what needs a custom API extension.

Deliverables:

• API coverage map (which endpoints and fields are available)
• List of required custom API extensions (if any), with AL code footprint estimate
• UI wireframes for every portal screen
• Auth architecture diagram
• Fixed-price proposal for the build phase

Cost: £2,500. Credited against the build if you proceed.

Phase 2: Build (6–12 weeks)

Fixed-price build based on the discovery sprint outputs. The build includes the portal frontend, the backend BFF layer, the BC API integration, authentication setup, and any required custom API extensions in AL.

The build process is structured in two-week sprints with demo reviews at the end of each sprint. You see a working, incrementally improving portal from week two onwards. No “big bang” delivery where everything appears on the last day.

Typical build cost: £25,000–£60,000 depending on complexity, number of screens, and whether custom AL extensions are required.

Phase 3: Hosting and operation

The portal runs on your chosen infrastructure (AWS, Azure, or Sysgraft-managed hosting). Monthly hosting and maintenance costs range from £300–£1,000 depending on traffic volume and SLA tier.

SLA options:

• Standard: 99.5% uptime, next-business-day support, £300/mo
• Enhanced: 99.9% uptime, 4-hour response, weekly BC API health checks, £600/mo
• Enterprise: 99.95% uptime, 1-hour response, proactive monitoring, dedicated infrastructure, £1,000/mo

Real features your customers get

Here is what a well-built customer portal over BC looks like in practice. These are capabilities we have shipped for UK manufacturers and distributors, not theoretical features.

Order tracking. Customer logs in and sees every order they have placed in the last 12 months. Status is live — pulled from BC in real time (with a cache layer for performance). Each order shows line items, quantities, expected ship date, and current status (Pending Approval, Released, Shipped, Invoiced). Colour-coded status indicators at a glance.

Invoice download. Posted invoices are listed with amounts, due dates, and payment status. Each invoice has a one-click PDF download. The PDF is the actual BC posted invoice document — pulled from the BC report engine or stored as an attachment in BC.

Live stock availability. Your customer checks whether an item is in stock before they call. The portal shows current available quantity, committed quantity, and expected receipt dates for back-ordered items. Data is cached for 60 seconds to avoid hammering the BC API, but is never more than a minute stale.

Proof of delivery retrieval. Warehouse shipments linked to POD documents (signed delivery notes, photos) are surfaced in the portal. Customer service teams can stop emailing PDFs. The customer downloads the POD themselves.

Account statements. A simple statement showing all transactions for a date range — invoices, payments, credit notes, opening and closing balance. Useful for finance teams on the customer side who are reconciling their own accounts payable.

Reorder from history. One of the most popular features. A customer looks at a previous order and clicks “reorder.” The portal creates a new sales order in Business Central via the /salesOrders POST endpoint. Line items, quantities, and pricing are pre-populated from the original order. The customer adjusts quantities and submits. The order appears in BC within seconds.

Query submission. Customers can submit queries (statement dispute, delivery query, product question) through the portal. These create entries in BC as either sales header notes or a custom inquiry table that your customer service team works from. The portal shows the status of each query (Open, In Progress, Resolved) and the response thread.

What about Business Central licensing?

A common concern: “If I give customers access to BC data through a portal, do I need additional BC licences?”

No. External users accessing BC data through an API-integrated portal do not require Business Central user licences. The portal is a third-party application calling the BC API via a service principal. Microsoft’s licensing terms treat this as an API integration, not user access. Your internal BC users retain their existing licences. Your customers do not need any BC licence.

This is explicitly covered in the Microsoft documentation on external users: users who access Business Central data through an integrated application (not through the BC client) do not require a BC subscription licence.

FAQ