Microsoft Business Central customer portal templates hit hard limits for multi-location wholesale. When to extend, when to build custom, and the fixed-scope math.
You searched business central customer portal template because your wholesale or multi-location operation runs on Microsoft Dynamics 365 Business Central and you need customers to place orders, check inventory, and view invoices without emailing your inside-sales team. The AppSource listings look fast. The partner demos look clean. Then you hit the wall: template portals assume one price list, one warehouse, one approval flow — and your business has three warehouses, customer-specific pricing tiers, and a rep-assignment rule that lives in a spreadsheet.
This page walks through where the standard Business Central B2B portal template (and the common Power Pages starter kits) break for distributors, which AL extensions actually close gaps, and when a fixed-scope custom portal becomes cheaper than fighting the platform. We build fixed-scope web applications on React/Next.js, mobile apps on React Native, and AI/LLM systems (RAG pipelines, agentic workflows) for companies like yours — regional wholesale distributors, multi-location operators, and technical SaaS founders in the US and EU.
The out-of-the-box Business Central customer portal template (via Power Pages or AppSource ISV solutions like Sana Commerce Cloud, Kensium, Visionet) gives you: customer self-registration with Azure AD B2C or Entra ID, order entry against the Sales Order table, real-time Item Availability by location, invoice history with PDF download, and a basic Power BI embedded dashboard. It assumes a single Company in BC, standard pricing via Sales Prices/ Trade Agreements, and approval workflows that map to Approval User Setup. If your catalog is under 5,000 SKUs, you have one warehouse, and pricing is list-less-discount, the template deploys in 4–6 weeks through a Microsoft partner.
Template portals break when: (1) multi-location inventory logic requires available-to-promise (ATP) across warehouses with transfer rules — BC’s standard Item Availability by Location doesn’t surface transfer lead times or allocation priorities; (2) customer-specific pricing lives outside Sales Price Worksheet (e.g., matrix pricing by volume tier, annual rebate agreements, or contract PDFs stored in SharePoint); (3) sales rep assignment is territory-based with override logic — the template has no concept of “rep owns account” vs “house account”; (4) order minimums, case-pack enforcement, or palletization rules vary by customer and item — standard Order Promising doesn’t enforce case multiples per ship-to; (5) credit hold/release needs real-time AR aging visibility and a “pay now to release” button — the template shows balance but not Payment Journal integration; (6) returns/RMA require photo upload, restocking fee calc, and credit memo auto-gen — not in any starter kit.
| Gap | Extension approach | Where it still falls short |
|---|---|---|
| Multi-warehouse ATP | AL extension on Item Availability page + custom Transfer Order logic | Requires Telemetry monitoring; debug in VS Code AL extension; no UI for customer-facing “ship from nearest” selector |
| Contract pricing matrix | Price Calculation event subscribers + External Document links to SharePoint | API throttling on OData v4 when 50+ buyers hit refresh; caching strategy needed |
| Rep assignment | Dimension-based territory + User Personalization | No mobile-first rep dashboard; Power App canvas app becomes separate project |
| Case-pack enforcement | Sales Line validation on OnBeforeInsertEvent | Error messages surface in BC client, not portal — needs custom API endpoint |
| Credit hold + pay-now | Payment Services (Adyen/Stripe) + AR Ledger Entry webhook | PCI SAQ-A scope expands; partner must be Payment Application certified |
| RMA with photos | Blob Storage + Power Automate → Credit Memo | Dataverse capacity costs spike; Power Pages file upload limit 25 MB |
Bottom line: each extension adds AL development hours, BC SaaS tenant testing cycles, and AppSource upgrade risk. Three extensions ≈ one custom portal sprint.
Custom portal wins when: (a) ≥3 template gaps from the list above — each extension is 40–80 hrs AL + testing; a React/Next.js portal on Azure Static Web Apps or Vercel with BC OData v4 + Azure API Management is 120–180 hrs fixed scope; (b) mobile field reps need offline order capture — React Native app shares TypeScript types with portal; (c) AI-assisted ordering (RAG over product catalog + order history) — Azure AI Search + Semantic Kernel agent calls BC API; templates have no AI layer; (d) brand/UX ownership — template CSS is locked; custom portal is your IP, portable if you migrate ERP.
Rule of thumb: if your annual portal-driven revenue > $2M and template TCO (partner retainer + AL dev + Dataverse capacity + upgrade regression) > $12k/yr, fixed-scope custom build pays back in 12–18 months. We scope these at $12k–$20k for portal + $10k–$12k for companion React Native field app — fixed price, 10–14 weeks, Terraform-provisioned AWS/GCP infra in your account.
Use this decision checklist (downloadable CSV at the bottom):
| Question | Template | Extend | Custom |
|---|---|---|---|
| Warehouses / ship-to locations | 1 | 2–3 | ≥3 with transfer rules |
| Pricing complexity | List less % | Matrix ≤5 tiers | Contract PDFs, rebates, annual agreements |
| Rep assignment logic | None | Territory dimension | Override, house accounts, split commissions |
| Order rules | None | Case pack only | Min order, palletization, customer-specific |
| Credit / payments | Balance view | Pay-now link | Real-time AR aging, partial release, ACH/CC |
| Mobile field reps | No | Power App canvas | React Native offline-first |
| AI-assisted ordering | No | No | RAG + agent on catalog/history |
| Annual portal revenue | <$500k | $500k–$2M | >$2M |
| Internal AL dev capacity | None | 0.5 FTE | None (you want fixed-scope partner) |
| Timeline to launch | 4–6 wks | 8–14 wks | 10–14 wks fixed scope |
Score: 0–3 Template, 4–6 Extend, 7+ Custom.
Power Pages (formerly Power Apps Portals) uses Dataverse as data layer. You still need Dual Write or Virtual Tables to sync Business Central → Dataverse → Portal. That adds: Dataverse capacity ($40/mo base + per-app/per-user), Dual Write latency (5–30 sec), schema drift risk when BC AL extensions change tables, and Power Fx logic that doesn’t travel. Custom React/Next.js hits BC OData v4 directly — no middle layer, no extra license, full TypeScript control, portable to any host. Choose Power Pages only if: you already have Dataverse for Dynamics 365 Sales, your IT team owns Power Platform governance, and portal is read-heavy (catalog, invoices) with <5 write flows.
The Business Central Portal Scope Checklist (CSV) includes: BC version + AL extension inventory; Company/ Dimension map; Number Series for orders/invoices/credit memos; Price Calculation method (standard vs custom); Ship-to hierarchy + Location ATP rules; Customer price group + Sales Price Worksheet usage; Approval User Setup + Workflow definitions; Payment Services provider + PCI scope; Entra ID B2B guest config; API throttling limits (BC SaaS: 100 req/30 sec/tenant); Dataverse capacity if Power Pages; Accessibility target; Load test criteria; Handoff deliverables (repo, Terraform, runbook, ADRs).
10–14 weeks from signed SOW to production cutover, including Terraform-provisioned infra, Playwright e2e suite, k6 load test, and handoff documentation. Template + partner: 4–6 weeks but with gaps. Extensions:
Need this built? Our team does fixed-scope fixed-price portal build — scoped, priced and delivered in weeks.
Mehedi Hasan · Senior Software Engineer