Power Platform + Business Central: The Full Stack for SMEs (2026)

What 'Power Platform for Business Central' actually means

Power Platform is Microsoft's low-code suite: Power Apps, Power Automate, Power BI, Power Pages, and Copilot Studio. Business Central is the ERP. Connecting them means you can extend BC—custom apps, automated workflows, richer reporting, external portals, AI agents—without heavy AL development or a rip-and-replace project.

There are two integration paths and the distinction matters. The first is the Business Central connector, a REST-based premium connector that exposes BC data and business actions to Power Apps, Power Automate, Copilot Studio, and Azure Logic Apps. The second is virtual tables: the Business Central Virtual Table app publishes BC tables into Dataverse so Power Platform can do full CRUD on them at runtime via OData, without copying the data out of BC.

In both cases the data and the business logic stay in Business Central. Power Platform reads and writes through the connector or through virtualized tables. That keeps BC as the system of record and avoids the data-residency and sync-headache problems that come with exporting ERP data into a separate database.

This page is the umbrella hub for the whole stack. For deep dives on individual components, see our dedicated guides on Business Central + Power Automate and Business Central + Power BI.

• →Power Platform = Power Apps, Power Automate, Power BI, Power Pages, Copilot Studio
• →Two integration paths: BC connector (REST APIs) and virtual tables in Dataverse (no data copy, full CRUD)
• →Data and business logic stay in BC; Power Platform reads and writes at runtime
• →Extends BC without heavy AL development or replacing the ERP

Architecture map: Business Central ↔ Dataverse ↔ Power Platform

Think of Business Central as the transactional core and Power Platform as the extension plane. BC holds companies, ledgers, inventory, and posting rules. Power Platform sits beside it: apps and portals for UX, flows for orchestration, Power BI for operational reporting, and Copilot Studio for conversational agents. Dataverse is the shared data and solution fabric for model-driven apps, Power Pages, and many governance/ALM controls—not a second ERP database when you use virtual tables correctly.

A practical SME topology looks like this. Production BC Online (one or more companies) is the system of record. A dedicated Power Platform production environment—preferably managed—hosts solutions that touch live BC data. A separate dev (and ideally test) environment mirrors the same connector and virtual-table patterns so makers never ship from Default. Optional: a Dataverse database in those environments for portal metadata, non-ERP reference data, and solution packaging; BC tables used as virtual tables remain live proxies via OData, not copies.

Traffic patterns differ by component. Power Automate and canvas apps usually call the premium BC connector (REST). Model-driven apps and many Power Pages CRUD screens use virtual tables published by the Business Central Virtual Table app into Dataverse. Power BI reads BC through API pages/queries (preferred) or legacy OData against the reporting replica. Copilot Studio agents use the BC connector for low-code CRUD tools, the BC MCP server for API-page-backed agent tools, or both when a cryptic API needs a hand-written tool description.

Keep identity and company boundaries explicit. Every production flow should pin environment and company names. Every agent should scope MCP configurations to the API pages it needs, not the whole tenant. Do not treat SharePoint lists or Excel Online as long-term ERP stores—use them only as temporary intake or export surfaces that write into BC through a controlled flow.

• →BC = system of record; Power Platform = UX, automation, analytics, agents
• →Virtual tables proxy BC into Dataverse; they do not copy ERP master data
• →Separate Power Platform environments for dev/test/prod; prefer managed for production
• →Pin company/environment on flows; scope MCP API surfaces on agents

AL extensions vs Power Apps: when to extend which way

SMEs often jump to Power Apps for every gap. That is expensive and fragile when the change belongs inside Business Central. Use AL extensions when the work is core ERP logic, posting, inventory, financial controls, or anything that must stay in BC's transaction boundary and upgrade path. Use Power Apps when you need a mobile or task UI BC role centers cannot deliver, multi-system screens, or rapid prototypes that should not ship as AL.

Power Apps is strongest for custom UI, warehouse/field mobility, and processes that stitch BC to Teams, SharePoint, or third-party systems. AL is strongest when you need BC business logic, permission sets, and upgrade-safe customization that finance will still trust after a major BC wave. Partners who only sell AL, or only sell low-code, will bias the answer—decide from the table below.

• →AL for ERP truth and controls; Power Apps for UI, mobility, and multi-system UX
• →Do not rebuild posting or inventory rules in a canvas app
• →Rapid prototype in Power Apps, then promote durable logic into AL if it becomes core
• →Virtual tables and connectors do not remove the need for BC licensing on BC data

Power Apps + Business Central: custom apps on ERP data

Power Apps lets you build canvas apps (free-form, pixel-controlled) and model-driven apps (data-first, generated from Dataverse) that read and write Business Central data. You connect to BC either through the premium BC connector or through virtual tables published to Dataverse.

Canvas apps suit task-specific interfaces—a warehouse picker, a field-service timesheet, a trade-show lead-capture form—where you want a tailored mobile experience without touching BC's role centers. Model-driven apps suit structured, relationship-heavy processes (vendor onboarding, multi-step approvals) where the data model drives the UI. Model-driven apps effectively require virtual tables for deep BC CRUD; canvas apps can use either path.

Because virtual tables expose BC data as if it lived in Dataverse, model-driven apps can do full create-read-update-delete on BC records without a sync job. The trade-off is documented limitations—no charts, attachments, images, BLOBs, or multiline strings through virtual tables, and restricted advanced search (unsupported predicates include Does Not Equal and Does Not Contain; limited AND/OR across columns; no filtering on calculated fields). Plan around these before you commit a screen to them.

• →Canvas apps for task-specific, mobile-tailored experiences (warehouse, field service, lead capture)
• →Model-driven apps for structured, relationship-heavy processes (onboarding, approvals)
• →Virtual tables enable full CRUD on BC data from model-driven apps without copying data
• →Virtual-table limits: no charts, attachments, images, BLOBs, multiline strings; restricted filtering

Power Automate + Business Central: cross-system workflows

Power Automate builds event-driven flows between BC and the rest of your stack—Outlook, Teams, SharePoint, Excel, Dataverse, and thousands of other services. The BC connector is the surface: it provides triggers (record created, modified, deleted, changed; approval requested) and actions (CRUD, find records, run BC business actions, deep links, adaptive cards for Teams).

Flows are embedded in the BC client. On most list, card, and document pages the 'Automate' action group lets users kick off context-aware templates from the record they are already on, and AL developers can add custom page actions that trigger flows for deeper integration. Instant flows that use 'For a selected record' appear in that Automate menu in the browser client.

Two practical notes for SMEs. First, the BC connector is a premium connector—automated and scheduled flows need a Premium-eligible license on the owner, and instant ('For a selected record') flows need Premium-eligible rights on every user who runs them. Second, records are limited to under 8 MB per call and the connector is throttled at 300 API calls per 60 seconds per connection, so high-volume environments need filtering or batching upstream.

We cover triggers, actions, approval flows, licensing traps, and limitations in depth in our dedicated Power Automate + Business Central guide.

• →Event-driven flows between BC and Outlook, Teams, SharePoint, Excel, and thousands of services
• →Embedded in the BC client via the 'Automate' action group; AL actions can also trigger flows
• →Premium connector—owner-licensed for automated/scheduled flows, invoker-licensed for instant flows
• →300 API calls / 60 seconds / connection and an 8 MB per-record cap—plan filtering accordingly

Top Power Platform + Business Central automation scenarios

Start with scenarios that remove email-and-spreadsheet glue, not with a platform rewrite. The highest ROI patterns for SMEs on BC are approvals that leave the ERP client, notifications into Teams, and light data sync with systems BC should not own.

Typical first wave: purchase or credit-limit approvals that route to managers outside BC; customer credit-hold alerts when orders are blocked; invoice or shipment status posted to a Teams channel; vendor onboarding that collects documents in SharePoint then creates the vendor in BC; inventory reorder alerts when availability crosses a threshold; and daily or weekly operational digests (open SO, overdue invoices) pushed to Excel Online or email. Credit-control templates—unblock customer, notify sales, update status—are common enough that partners ship short demos of them.

Defer high-volume master-data polling, mass item updates, and anything near the 300 calls/minute connector ceiling until you have filtering, batching, or an AL/API design. Prefer BC business events and record triggers over schedule-based full-table scans.

• →Prioritize approvals, notifications, and onboarding before complex sync
• →Keep financial and inventory rules in BC; automate signals and UX around them
• →Avoid unfiltered scheduled scans against large tables
• →Pair high-value scenarios with a license count before you scale makers

Power BI + Business Central: reporting and dashboards

Business Central online ships with built-in Power BI integration. BC maintains a read-only database replica so reporting queries do not impact transactional performance, and it exposes operational data through API pages and queries (preferred) or legacy OData web services, all consumed by the Power BI connector.

The integration is layered. Embedded reports appear inside BC as Role Center parts and list-page FactBoxes—users can pin Power BI report parts, pages, or scorecards on pages that include a Power BI part, and AL developers can add report parts programmatically. The Power BI service hosts full interactive dashboards that can be shared. Power BI Desktop is where you build custom semantic models and reports on top of the same feeds.

Microsoft publishes a dedicated BC Power BI app for each functional area—Finance, Sales, Purchasing, Inventory, Inventory Valuation, Projects, Manufacturing, Subscription Billing, Sustainability—each bundling a semantic model and a library of reports. Audit the app for your area before building anything custom; the report your finance team is asking for often already exists.

For the connection steps, default reports by area, and the licensing traps that catch SMEs, see our dedicated Business Central + Power BI guide.

• →Built-in integration; BC keeps a read-only replica so reporting does not slow transactions
• →Data exposed via API pages/queries (preferred) or legacy OData web services
• →Three layers: embedded reports in BC, dashboards in the Power BI service, models in Power BI Desktop
• →Pre-built BC Power BI apps per functional area—check before building custom

Power Pages + Business Central: external B2B portals

Power Pages is the website-building component of Power Platform—external-facing pages built on Dataverse. To reach Business Central data you go through the same two paths as the rest of the suite: the BC premium connector (good for read-heavy and workflow-triggered pages) or BC virtual tables published into Dataverse (good when the portal needs full CRUD on live ERP records without a sync job). Microsoft documents Power Pages integration with BC on virtual tables as a supported path for external access patterns.

Typical SME use cases are B2B self-service: a customer portal for order status, invoice history, and statement download; a vendor portal for purchase-order acknowledgement and invoice submission; a dealer or agent portal for quoting. Because Power Pages is licensed per authenticated user per month, it suits portals with a manageable external user count rather than high-volume public traffic.

The guardrails matter. Virtual tables still carry their documented limits (no attachments, images, BLOBs, or multiline strings), so anything involving document upload or binary content needs a workaround—typically a flow that writes the attachment directly to BC through the connector while the portal stores only metadata in Dataverse.

• →External-facing portal builder on Dataverse; reaches BC via connector or virtual tables
• →Strong fit for B2B self-service: customer, vendor, and dealer portals
• →Per-authenticated-user monthly licensing—plan for manageable external user counts
• →Attachment/binary limits on virtual tables usually need a Power Automate workaround

Copilot Studio + Business Central: AI agents on ERP data

Copilot Studio is where you build agents and copilots that ground their answers in your Business Central data. Microsoft documents two first-class connection options for agents: the Business Central connector for Power Platform, and the Business Central Model Context Protocol (MCP) server. You can use either alone or both together—for example when an API description is too cryptic for the model and you need a hand-tuned connector tool with a clear natural-language description.

Use the connector when the agent needs simple CRUD as the signed-in user, respects BC permissions, and benefits from low-code actions (Find records, Create record, Run action) plus Power Automate hand-offs. Use the MCP server when the agent must orchestrate multi-step AI workflows against standard or custom API pages, when you need explicit allow-lists of create/read/update/delete and bound actions per configuration, or when performance and security policies require direct API-page tools rather than abstracted connector actions. MCP configurations map each allowed API-page operation to an agent tool; leave configuration blank for default read-only discovery across exposed API pages, or pin a configuration for write scopes.

2026 release wave 1 deepened the MCP path: enhanced agentic MCP experiences, broader Business Central data unlocked for the MCP server (including more Microsoft-published APIs and API queries useful for Power BI-style aggregates), admin-center MCP connectivity, and AL troubleshooting hooks. Practitioners also report real-world friction—connection errors on the preview MCP connector, known-issue windows on specific BC builds (for example v28.3 access problems called out by MVPs), and non-obvious setup when wiring BC MCP into third-party MCP clients. Treat MCP as production-ready only after you enable it per environment, configure allowed operations, and regression-test tools after each BC update.

For SMEs the realistic patterns remain internal productivity copilots (open orders, credit holds, invoice status with deep links) and lightweight external copilots on a Power Pages site. Agents can create sales orders, check credit, post payments (when MCP write tools allow it), and trigger approvals or flows. Publish channels include Teams, Microsoft 365 Copilot, and websites. Two cautions never go away: scope grounding to specific tables or API pages so agents do not invent fields, and estimate Copilot Studio capacity (message packs or Microsoft 365 Copilot entitlements) before you promise always-on chat to the warehouse floor.

• →Two official paths: Power Platform BC connector and BC MCP server (use both when useful)
• →Connector for simple user-context CRUD; MCP for API-page tools and agentic orchestration
• →2026 wave 1 expanded MCP data coverage and agent tooling—still validate after each BC update
• →Scope tools tightly and budget Copilot Studio capacity before broad rollout

BC connector vs virtual tables: choosing the integration path

Almost every architectural question on Power Platform + Business Central reduces to which of the two integration paths you lean on. The table below is the decision summary we walk SMEs through.

Power Platform + Business Central licensing in 2026

Licensing is where SME budgets leak. Business Central Essentials or Premium does not mean every Power Platform use case is free. The BC connector is premium, so non-trivial apps and flows that use it need Premium-eligible rights. Standalone list prices (USD, paid yearly, Microsoft public pricing pages as of 2026): Power Apps Premium about US$20/user/month (about US$12/user/month at 2,000+ seats), Power Automate Premium about US$15/user/month, Power Automate Process about US$150/bot/month for unattended/capacity bots, Power BI Pro about US$14/user/month, and Power BI Premium Per User about US$24/user/month. Power Pages is licensed per authenticated user per month. Copilot Studio is consumed via message packs or Microsoft 365 Copilot entitlements.

The 2026 licensing shift SMEs must not miss: effective January 2, 2026, Microsoft ended sale of the Power Apps per app SKU for new customers (list price historically about US$5/user/app/month). Existing enterprise customers on that SKU can generally continue and renew under current agreements; channel nuance exists (CSP treatment has varied through 2026 announcements). For most new BC + Power Apps rollouts the production paths are Power Apps Premium (unlimited apps per user) or Azure pay-as-you-go metering—commonly cited around US$10 per active user per app per month—plus capacity and premium-connector implications. Do not build a business case that still assumes cheap per-app seats for new logos.

Microsoft lists Dynamics 365 Business Central among the Dynamics SKUs that provide premium Power Apps and Power Automate usage rights for managed environments—so BC-licensed users are not automatically forced into a second Premium SKU for every in-context scenario. That does not eliminate seats for makers and invokers outside BC context, Process capacity for unattended bots, Power BI seats for report consumers, or Power Pages external users. Treat BC rights as a starting entitlement, not a blank check.

Four traps catch SMEs every time. First, instant flows ('For a selected record') require every user who runs them to have Premium-eligible rights, not just the flow owner—that multiplies cost across sales or warehouse teams. Second, any Power Platform user who accesses Business Central data through virtual tables must also exist as a user in Business Central; community and partner guidance treat BC data access as requiring BC licensing, not Power Apps alone. Third, Azure pay-as-you-go meters look cheap for pilots but are unbounded for steady production—prefer named Premium seats for anything more than a handful of people run daily. Fourth, M365 'includes Power Apps' only covers standard connectors and basic scenarios; the BC connector is premium, so ERP-touching apps leave the free tier immediately.

Managed environments (recommended once you leave the default environment) require qualifying premium licenses on active users. Microsoft has been tightening compliance messaging around managed environments through 2026, including admin and end-user notifications when users lack appropriate licenses.

• →BC Essentials/Premium does not make every Power Platform scenario free; the BC connector is premium
• →Per App is end-of-sale for most new buyers as of Jan 2, 2026—budget Premium or carefully capped PAYG
• →2026 public list: Power Apps Premium ~US$20/user/mo; Power Automate Premium ~US$15/user/mo; Power BI Pro ~US$14; PPU ~US$24
• →Instant flows need rights on every invoker; virtual-table users must exist in BC

Governance and ALM for Power Platform on Business Central

Citizen development without guardrails is how SMEs get shadow apps that break on Monday with no owner, no DLP, and no rollback. Turn on auditing in the Power Platform admin center, define data loss prevention (DLP) policies that classify connectors (block consumer social connectors; put BC and finance connectors in a controlled business group), and stop building production apps in the default environment. Microsoft Mechanics and partner guidance in 2026 also stress Purview labeling, DLP, and audit continuity as Copilot Studio agents join the same estate—treat agents as production workloads, not side chats.

Use managed environments for anything that touches live BC data. Limit sharing, require solution-aware apps and flows, and move deployments through Power Platform pipelines (or Azure DevOps) from dev to test to production. Virtual tables live in the Microsoft-managed MicrosoftBusinessCentralERPVE solution—your ISV or project solutions should Add existing virtual tables as dependencies rather than trying to export the Microsoft solution. Missing virtual tables can be made visible on import when dependencies are declared correctly.

Environment strategy for a 20–200 person SME can stay simple: Default locked down (personal productivity only), one shared Dev with maker training rules, optional Test that mirrors Prod connectors, and one managed Prod tied to production BC. Name owners for every production flow, app, and agent; document the BC company and API surfaces they touch; review premium connector use monthly. Practitioner chatter is consistent: M365 already seeds Power Automate/Power Apps rights for many users—if you do not govern environments and connectors, you will discover sprawl only after an incident.

• →Enable auditing, DLP, and tenant isolation; block unapproved connectors by default
• →Production BC-connected work belongs in managed environments, not Default
• →ALM via solutions + pipelines; reference BC virtual tables with Add existing
• →Govern Copilot Studio agents like production apps; assign owners and review sprawl on a schedule

Limitations and gotchas to plan around

Every Power Platform component that touches Business Central has a documented limit that becomes a project risk the day you ignore it. The ones below are the recurring offenders across SME implementations.

Virtual tables: no charts, attachments, images, BLOBs, or multiline strings; restricted filtering (unsupported predicates include Does Not Equal and Does Not Contain; limited AND/OR across columns; no filtering on calculated fields). Connector: 300 API calls per 60 seconds per connection, under 8 MB per record for create/get-style actions. Power Automate: action/request limits per license tier and on-demand conversation timeouts. Power BI: the BC path is operational reporting against API/OData feeds and the reporting replica—not real-time OLTP write-back. Licensing: virtual-table consumers need BC user presence; instant flows multiply Premium seats. MCP/agents: server must be enabled per BC environment; write tools require explicit MCP configuration; retest after wave updates when known issues land on specific builds.

Also decide when BC standard workflows are enough. Native BC approval workflows still fit simple in-ERP purchase or sales approvals with BC-only participants. Reach for Power Automate when approvers live outside BC seats, when you need Teams adaptive cards, multi-system branching, or document collection in SharePoint before a BC create—then keep the financial decision inside BC and automate only the signal path.

• →Virtual tables: no attachments, images, BLOBs, multiline strings, or calculated-field filtering
• →BC connector throttled at 300 calls/60s/connection; under 8 MB records
• →Power Automate: per-license request limits; invoker licensing on instant flows
• →MCP agents need environment enablement, scoped configs, and post-update retests
• →Prefer BC standard workflow for simple in-ERP approvals; Power Automate for cross-system routes

Frequently asked questions