What “Real-Time” Actually Means in a Business Central Portal
The phrase “real-time data access” gets used loosely. In the context of a Business Central customer portal, it has a specific technical meaning: the portal reads from Business Central’s API or OData feed, not from a copy or a sync.
Some portal implementations use periodic sync jobs. A customer logs into the portal at 2 PM, but the sync last ran at midnight, so they see data that’s 14 hours out of date. Their delivery status shows “pending” when the shipment actually left your warehouse this morning.
A true real-time connection means the portal queries Business Central at the moment the customer loads the page. The data is current to the minute. If an invoice was posted an hour ago, the customer can see it. If an order status changed this morning, the portal reflects that change without waiting for a scheduled sync.
This distinction matters enormously for B2B relationships, where customers are often making operational decisions based on what they see in your portal.
The Data That B2B Customers Need Access To
Not every Business Central record needs to be customer-facing. But several data categories are high-value for customer visibility.
Sales orders and delivery status. Customers want to know whether their order is confirmed, when it shipped, and when it’s expected to arrive. Without portal access, they email or call. With a Business Central customer portal, they check directly.
Invoices and payment history. B2B accounts departments need to track invoices against payments. A portal that shows invoice status, due dates, and payment records saves the back-and-forth between your AR team and the customer’s accounts payable team.
Item availability and pricing. For customers who place repeat orders, knowing current stock levels and contract pricing before submitting a new order reduces friction and errors. Business Central holds both. The portal can surface both.
Project and service order status. For service businesses running projects through Business Central, customers benefit from seeing milestone completion, resource allocation, and billing status without waiting for manual status reports.
Posted documents. Posted sales invoices, credit memos, and shipment documents that your team accesses through Business Central can be made downloadable through the portal. Customers retrieve their own documentation without requesting it from your team.
How the Integration Architecture Works
A Business Central customer portal connects to Business Central through one of three methods.
OData APIs. Business Central exposes standard OData endpoints for most entity types: customers, sales orders, invoices, items, and more. A portal that queries these endpoints directly can read any Business Central record that’s been exposed through a web service.
Business Central Custom APIs. For more specific data requirements, custom API pages in Business Central can expose exactly the fields and entities needed by the portal, with the filtering and business logic built in. This is the cleanest approach when standard OData doesn’t cover everything.
Power Platform connectors. For organizations using Power Apps Portals or other Microsoft platform tools, the Dataverse connector route is available. This is a valid path but adds another platform dependency.
For most Business Central customer portal implementations, the OData or custom API approach is more direct and performs better. It doesn’t require Dataverse configuration, which simplifies the architecture considerably.
Why Role-Based Access Is Critical
Business Central holds data for every customer account. When you build a portal, each customer can only see records linked to their account. That isolation is not automatic. It requires explicit configuration at the portal level.
The access logic works as follows. A portal user logs in. The portal identifies their Business Central customer record from the authentication profile. All subsequent queries filter results to that customer’s number. An invoice query returns invoices for that customer only. A sales order query returns that customer’s orders only.
Any gap in that filtering logic creates a data exposure risk. A customer could see another customer’s invoices or order details. This isn’t a hypothetical concern. It’s the most common security failure mode in poorly configured B2B portals.
Proper implementation enforces these filters at the API query level, not just at the display level. Even if a customer attempts to manipulate a URL or API call, the backend query still applies the customer filter. The portal never returns records outside the authenticated customer’s account.
What Changes for Your Internal Team
The operational shift from a customer portal implementation is often as significant for your team as for your customers.
Support request volume drops. Customers who can see their own order status, invoice history, and delivery timeline don’t call to ask about those things. Ticket deflection rates of 20% to 40% for informational queries are typical across B2B industries.
AR processes accelerate. When customers have direct access to their invoice and payment records, disputes and payment delays due to “I never received that invoice” decrease. Customers can see the invoice in the portal the day it’s posted in Business Central.
Data accuracy improves. Some Business Central customer portals allow customers to update specified records: contact details, delivery addresses, preferred payment methods. When customers maintain their own records, the data quality in Business Central stays current without manual audit cycles.
Fewer manual reports. If your team currently sends weekly or monthly status reports to key accounts, a portal with real-time data access removes that work. Customers check the portal when they need to know something, rather than waiting for scheduled updates.
Configuring the Right Customer Experience
Real-time data access is only as valuable as the experience built around it. A portal that exposes raw Business Central data in a table format isn’t useful to most customers. It needs to be structured around how they actually think about their relationship with your business.
A few principles that apply consistently.
Group by relationship context, not by Business Central entity. Customers don’t think in terms of “Posted Sales Invoices” and “Sales Orders.” They think in terms of “my orders,” “my bills,” and “my deliveries.” The portal navigation should reflect that framing.
Show status at a glance. The most frequent use case for most B2B portals is status checking. Order statuses, payment statuses, and delivery statuses should be visible immediately on login, not buried in submenus.
Limit the editable fields. Not every Business Central field should be customer-editable. Define explicitly which fields customers can update (delivery address, contact details, PO references) and which are read-only. This keeps your internal data model clean.
Make documents accessible. Invoice PDFs, order confirmations, and shipping documents should be downloadable in one click. If a customer has to navigate three pages to find a document, they’ll email your team instead.
Building on Business Central vs. Using a Third-Party Portal
Microsoft’s first-party portal option for Business Central is Power Pages (previously Power Apps Portals). It connects to Business Central through Dataverse and provides a low-code configuration interface.
Power Pages works well for organizations already invested in the Microsoft Power Platform ecosystem. But it has practical limitations for Business Central customer portal use cases. The Dataverse connection requires a data replication step, which adds latency compared to a direct OData connection. Licensing is per-authenticated-portal-user per month, which compounds quickly for businesses with large customer bases. And the customization ceiling for complex B2B workflows can require Power FX development that many teams don’t have the capacity for.
Third-party Business Central customer portal solutions, such as CRMJetty’s Business Central Customer Portal, connect to Business Central directly through its APIs without the Dataverse intermediary. They’re designed specifically for B2B customer self-service use cases rather than general-purpose portal scenarios. And they typically operate on flat-fee pricing, which doesn’t scale costs per user.
For organizations with a defined B2B customer base that primarily needs access to sales, billing, and service data, the direct API approach tends to deliver better performance and simpler architecture than the Power Platform route.
Common Implementation Mistakes
Most Business Central customer portal implementations that fail do so for one of three reasons.
Access control is configured at the UI level only. The portal hides records from unauthorized users in the display layer but doesn’t enforce filtering in the API queries. This creates security gaps that aren’t visible in standard testing.
The scope is too broad at launch. Exposing every Business Central entity to customers from day one creates configuration complexity and increases the surface area for errors. Start with the highest-value data types (orders, invoices, delivery status), validate those workflows with a pilot group, and expand from there.
Customer adoption is assumed rather than planned. A portal is only useful if customers use it. Communication, simple onboarding documentation, and direct outreach to key account contacts all matter. Companies that deploy and assume customers will find it on their own tend to see low adoption
The Practical Case
A Business Central customer portal isn’t a technical project for its own sake. It’s an operational decision about where you want your customers to get their information and how much staff time you want to spend delivering it.
If your AR team regularly fields questions about invoices that are already in Business Central, that’s a portal problem. If your logistics team sends manual status updates to accounts, that’s a portal problem. If your project managers spend Friday afternoons pulling status reports that customers could see directly, that’s a portal problem.
Real-time data access means customers get accurate answers when they need them. Your team spends less time providing those answers. That’s the case, plainly stated.