Business Central Customer Portal for Multi-Location Operators: Build vs Buy

If you run regional wholesale distribution or manage multiple retail sites on Microsoft Dynamics 365 Business Central, you already know the off‑the‑shelf customer portal leaves gaps. It cannot handle location‑specific pricing, stock visibility per warehouse, or the approval flows your buyers actually use. A Business Central customer portal for multi‑location operators is not a feature toggle; it is a custom layer on top of your BC instance that exposes the right data to the right role, at the right time.

This post is for operators and IT leads who need a portal that works like your business, not like a generic SaaS demo. We will map the architecture, the build‑vs‑buy math, and the scope checklist you need before you talk to any developer. Wolverine Solution builds fixed‑scope portals on BC for regional distributors and multi‑site operators in the US and EU; we will use this page to show exactly how that works.

What is a Business Central customer portal for multi‑location operators?

A portal that extends your Business Central data to external users — buyers, distributors, and field teams — without exposing your core ledger. It sits on BC via OData or SOAP endpoints, authenticates through Azure AD or BC web services, and presents a role‑tailored interface: a wholesale buyer sees available stock across your distribution centers, requests a quote, and tracks a PO; a field sales rep checks inventory at the nearest warehouse on a phone; a head office manager approves credit holds from a multi‑entity dashboard.

The key difference from a generic portal is location awareness. Every screen must know which legal entity, warehouse, or ship‑to address the user belongs to. That logic lives in the integration layer, not the UI. A custom build on BC handles this by mapping BC dimensions — Location Code, Dimension Set ID, Item Ledger Entry — into a clean customer‑facing model. You get NetSuite‑level flexibility without ripping out your ERP.

Why off‑the‑shelf portals fail for multi‑location operators

Microsoft’s own portal and partner solutions assume a single‑entity, single‑warehouse model. They are built for the 80% case: a manufacturer with one factory and a standard price list. Your operation is the other 20%.

Common failure points:

Pricing — Generic portals show one price. You need location‑based pricing, tiered discounts per business unit, and customer‑specific contract rates pulled from BC sales lines.
Stock visibility — A buyer in Dallas cannot see inventory in your Memphis warehouse because the portal only queries the primary Location Code. Offline sync for field sales apps is even harder.
Approval flows — Off‑the‑shelf portals route everything to one approver. Your credit manager in Chicago should see holds for EU entities, while the US credit team sees its own.
Integration depth — Partner portals are pre‑built for BC standard fields. If you track BOM revisions, service contracts, or drop‑ship flags, the portal goes dumb.

The result is a portal that works for simple orders and breaks for anything real. Operators end up exporting BC reports to Excel, which is what the portal was supposed to replace.

How a fixed‑scope custom portal works

A custom BC portal is a web application (typically React or Next.js for the front end, Node.js or .NET for the API) that talks to Business Central through authenticated endpoints. The scope is fixed: you agree on the screens, the integrations, and the data model before a single line of code is written.

Typical architecture:

Authentication — Azure AD single sign‑on, tied to BC user roles. A buyer gets a customer portal login; a warehouse picker gets a field app login; an admin gets a multi‑entity dashboard.
Data layer — The API pulls from BC via OData and caches hot data (product catalog, open orders) in PostgreSQL or Redis for speed. Write‑backs go through BC page APIs or data entities, not direct table access.
Location logic — Every call includes Dimension Set ID or Location Code context. The UI filters stock, pricing, and shipping options based on the user’s default or selected location.
Offline support — For field sales or warehouse picking, the app uses Service Workers and a local SQLite queue. Conflicts are resolved by BC posting rules, not by a human reconciling spreadsheets.

This is not a platform you buy; it is a fixed‑scope build. Wolverine Solution delivers it as a Statement of Work with a price band, a delivery date, and acceptance criteria. You own the code, the Terraform scripts, and the BC integration in your own Azure subscription.

Build vs buy decision matrix

Factor	Off‑the‑shelf portal	Custom build on BC
Cost (first 3 years)	$15k–$40k subscription + implementation	$25k–$80k fixed SOW (one‑time)
Location‑based pricing	Not supported	Native via BC dimensions
Multi‑entity approvals	Single approver per role	Custom routing by entity, amount, or product line
Field sales offline mode	None or limited	SQLite queue, conflict rules defined
Integration depth	Pre‑built fields only	Any BC data entity or page API
Ownership	Vendor controls roadmap	You own the code and data
Maintenance	Vendor‑managed, you pay	In‑house or retainer; we can hand over docs

The math changes if you have more than one warehouse, more than one legal entity, or buyers who expect real‑time stock per location. At that point, a generic portal costs you in lost orders and manual workarounds.

Cost of a custom Business Central customer portal

A fixed‑scope BC portal for multi‑location operators falls into three bands:

$25k–$40k — Core portal: catalog, cart, order tracking, basic location filter, Azure AD login. 8–12 weeks.
$40k–$60k — Adds location‑based pricing, custom approval workflows, field sales app with offline sync, document management (SD, CO, BOL). 12–16 weeks.
$60k–$80k — Full multi‑entity: dimensional security, drop‑ship support, RAG chatbot for product docs, Terraform CI/CD pipeline. 16–20 weeks.

These are fixed‑price SOW bands, not time‑and‑materials. You get a scope document, a delivery date, and a list of what is included. web application development for the technical breakdown.

What to include in your portal scope

Before you talk to any developer, write down the must‑have screens and rules. A good starting checklist:

Customer login — Azure AD or BC credentials, role‑based dashboards.
Product catalog — Filter by warehouse, item category, vendor.
Location selector — Ship‑to, pick‑up, or default from BC customer card.
Pricing — Contract price, quantity breaks, location surcharges.
Stock — Available, on‑order, allocated per warehouse.
Order entry — Cart, PO upload, BC sales invoice creation.
Order tracking — Real‑time status from BC shipments.
Approvals — Credit holds, special pricing, backorders routed by entity.
Offline mode — Field sales app syncs when back online.
Reporting — Open orders, AR aging, sales by dimension.

Anything not on this list is a change order. That is how fixed scope protects your budget.

How Wolverine Solution builds these portals

We are a Montréal‑based fixed‑scope agency serving US and EU clients. For BC operators, we start with a discovery workshop on Zoom (4 hours, free) where you, your ops lead, and our solution architect map the current pain. We then deliver a SOW with the scope checklist above, a Terraform architecture diagram, and a React component list.

Build process:

Discovery — Map BC data entities, user roles, and approval rules.
Architecture — Define OData endpoints, Azure AD groups, PostgreSQL schema.
Build — Front end in React/Next.js, API in Node.js, integration via BC page APIs.
Test — Acceptance criteria signed off by your ops lead; UAT on a sandbox BC instance.
Deploy — Terraform scripts stand up Azure resources; CI/CD pipeline ships updates.
Handover — You get the GitHub repo, Terraform state, and runbooks. We can stay on a monthly retainer for changes.

We also offer embedded product strategy for founders who need a roadmap beyond the first portal. product strategy for details.

FAQ

How long does a custom BC portal take to build?
A core portal with catalog, cart, and tracking takes 8–12 weeks from signed SOW to UAT. Adding location‑based pricing and offline field app extends to 12–16 weeks. Multi‑entity builds with dimensional security take 16–20 weeks. The timeline is fixed because the scope is fixed; no BC integration is started until the data model is locked.

Can you build on top of our existing Business Central instance?
Yes. We use BC OData endpoints and page APIs to read and write data without touching the SQL database. Your BC instance stays as the system of record. We deploy the portal in your Azure subscription, so you keep full control of the infrastructure.

Do we need a developer portal or partner center access?
No. We work with BC web service permissions only. If you use Azure AD, we configure app registrations for the portal to authenticate. No partner center access is required, and we never modify BC tables or codeunits.

What if we want a chatbot or AI search on the portal?
We can add a RAG pipeline that grounds answers in your BC product docs, SD notes, and item cards. The chatbot runs on Azure OpenAI with evals to prevent hallucinations. This is a separate SOW line item, typically $15k–$25k on top of the portal build.

Ready to scope your portal?

If you operate more than one warehouse or legal entity on Business Central, a generic portal will not work. Wolverine Solution builds fixed‑scope BC portals that handle location‑based pricing, multi‑entity approvals, and offline field sales — for regional distributors and multi‑site operators in the US and EU.

Book a free discovery workshop today. We will map your BC data, define the portal scope, and give you a fixed‑price SOW in two weeks. No retainers, no open‑ended contracts.

Need this built? Our team does fixed-scope fixed-price portal build — scoped, priced and delivered in weeks.