Business Central + Power Automate: Automate BC Workflows (SME Guide)

What Power Automate does with Business Central

Power Automate is a Microsoft service that creates automated workflows (called flows) between Business Central and other apps and services without writing code. A flow listens for something that happens in one system and then carries out one or more actions in another.

For a Business Central customer, that means a record event in BC - a customer created, a sales order modified, an approval requested - can automatically post a Teams message, send an Outlook email, write a row to an Excel file, update a Dataverse table, or kick off a multi-step approval chain across systems.

Power Automate is embedded directly in the BC client. On most list, card, and document pages, the 'Automate' action group (or 'More options' on some devices) lets users create automated, approval, or instant flows from the record they are already looking at, using context-aware templates.

• →Connects BC to Outlook, Teams, SharePoint, Excel, Dataverse, and thousands of other services
• →Triggered by BC record events (create, modify, delete, change) or run on demand from a selected record
• →Embedded in the BC client via the 'Automate' action group on list, card, and document pages
• →AL developers can also add page actions that trigger flows for deeper integration

The Business Central connector explained

The Dynamics 365 Business Central connector is what Power Automate uses to talk to BC. It is classified as a Premium connector for Power Automate, Power Apps, and Copilot Studio, which has licensing implications we cover below.

The connector exposes a consistent set of triggers and actions, all currently at version 3 (V3). It is the same connector whether you build the flow from inside BC, from powerautomate.com, or from Power Apps.

Two newer capabilities are worth flagging up front: the 'When a business event occurs (V3)' trigger and the 'Dynamics 365 Business Central MCP' are both in Preview, so treat them as evaluation tools rather than production dependencies until they go generally available.

• →Premium connector - required for any flow that reads or writes BC data
• →Surface for triggers and actions is consistent across BC client, powerautomate.com, and Power Apps
• →Business event trigger and Business Central MCP are currently in Preview

Power Automate triggers for Business Central

Triggers are the events that start a flow. The BC connector splits them into two families: generic record triggers that fire on any table event, and domain-specific approval triggers that fire when BC's native approval system requests sign-off.

The generic triggers are 'When a record is created (V3)', 'When a record is modified (V3)', 'When a record is deleted (V3)', and 'When a record is changed (V3)'. These cover the vast majority of automation use cases - anything from 'notify me when a new customer is added' to 'sync items to a price list when they change.'

The fifth trigger, 'For a selected record (V3)', is different. It defines an instant flow that a user runs manually from inside BC on the record they have selected. It cannot be run standalone from powerautomate.com - it only fires from the BC client with a record in context.

Approval triggers are purpose-built for BC's approval engine: 'When a customer/vendor/item approval is requested', 'When a general journal batch/line approval is requested', and 'When a sales/purchase document approval is requested'. Any Power Automate approval workflow template built on these triggers also appears in BC's own workflows list.

Power Automate actions for Business Central

Actions are what a flow does after it triggers. The BC connector provides a full CRUD surface plus a few specialized actions for richer scenarios.

The core record actions are Create record (V3), Get record (V3), Update record (V3), and Delete record (V3). For queries, Find records (V3) returns a list matching a filter and Find one record (V3) returns a single match - useful for lookups inside a larger flow.

Run action (V3) lets a flow execute a BC business action (posting, releasing, calculating) rather than just reading or writing fields. Get URL (V3) returns a deep link to a record, and Get adaptive card (V3) produces a rich adaptive card for Microsoft Teams so approvers can act without leaving the conversation.

• →Create / Get / Update / Delete record (V3) for full CRUD on any BC table the connector exposes
• →Find records (V3) and Find one record (V3) for filtered lookups inside a flow
• →Run action (V3) to invoke BC business actions such as posting or releasing
• →Get URL (V3) for deep links and Get adaptive card (V3) for rich Teams cards

Automated, scheduled, instant, and approval flows

Power Automate flow types behave differently in how and under whose authority they run - a distinction that matters for both security and licensing.

Automated flows run under the flow owner's context: every action the flow takes in BC happens as that owner, regardless of what triggered it. Scheduled flows (recurrence-based) work the same way - they run as the owner on a timer.

Instant flows built on 'For a selected record (V3)' are the exception: they run under the invoker's context. When a user clicks the flow from inside BC, the actions execute as that user, which keeps permissions honest for manual, record-level actions.

Approval flows combine the two. The trigger (an approval requested in BC) fires under the owner's context, but the approval itself can route to anyone - including people who do not have a BC license - because the Power Automate Approvals connector is a standard connector broadly available with Power Automate access.

Approval flows: the strongest BC use case

Approvals are where Power Automate adds the most visible value for BC customers. BC has its own native workflows and approvals system, so Power Automate is not a replacement - it coexists as an additional, embeddable option that excels at multi-system approvals and rich notifications.

A typical pattern: a sales document approval requested in BC triggers a Power Automate flow that posts an adaptive card in Teams, collects an approve or reject response from a manager (or an external approver who does not use BC at all), and writes the outcome back to BC. The whole chain runs without anyone leaving the conversation.

There is one trade-off to plan for: Power Automate approvals live in the Power Automate Approvals service, not in BC's native approval entries. That means the approval status and approver details are not natively visible inside Business Central the way BC-native approval workflows are. For SMEs that need a single pane of approval status, plan to either mirror the outcome back into a BC field or accept the split view.

• →Multi-system approvals that span BC, Teams, Outlook, and external email approvers
• →Adaptive cards let approvers act from Teams without opening BC
• →External approvers do not need a BC license - only the flow owner does
• →Approval status sits in Power Automate, not BC's native approval entries - a visibility trade-off

Common SME automation patterns

For small and mid-market teams, the highest-ROI Power Automate flows with BC tend to cluster around a handful of repeatable patterns.

The first is customer onboarding: when a customer is created in BC, post a welcome message in a Teams channel, create a row in a SharePoint onboarding tracker, and send an Outlook welcome email from a shared mailbox. The second is sales-document approvals: route purchase orders or sales quotes over a threshold to a manager via an adaptive card, with the outcome written back to BC.

The third is master-data sync: when an item or customer changes in BC, push the change to a Dataverse table, a price-list spreadsheet, or an e-commerce connector so downstream systems never drift. The fourth is finance close helpers: on a schedule, pull open invoices into an Excel or Power BI dataset, or notify the collections owner when an invoice crosses overdue thresholds.

• →Customer onboarding: BC customer created drives Teams + SharePoint + Outlook welcome chain
• →Sales approvals: threshold-based PO/quote routing with adaptive cards and write-back
• →Master-data sync: BC changes propagated to Dataverse, Excel, or e-commerce
• →Finance close: scheduled pulls of invoice data and overdue notifications

Licensing: why the premium connector matters

Because the BC connector is Premium, every flow that touches it requires each relevant user to have a Power Automate Premium license (or an equivalent entitlement). For automated and scheduled flows, only the flow owner needs the Premium license. For instant flows built on 'For a selected record (V3)', every user who runs the flow needs the Premium license - a budget item that catches SMEs off guard.

Dynamics 365 Business Central licenses include limited Power Platform entitlements, but the scope of those entitlements depends on the BC tier and the Microsoft licensing era. Treat any assumption that 'BC users already have premium connector rights' as something to verify against the customer's actual license agreement rather than a blanket rule.

If the flow needs to run unattended under a service account rather than a named user, Power Automate Process (per-flow) licensing applies. For SMEs, the practical rule is: minimize the number of premium-connector flows, prefer automated over instant flows where possible, and audit who actually triggers each instant flow.

• →BC connector is Premium - automated/scheduled flows need one Premium license on the owner
• →Instant flows need a Premium license on every user who runs them
• →D365 BC licenses include some Power Platform entitlements - verify against the customer's tier
• →Unattended/service-account flows need Power Automate Process licensing

Limitations to plan around

Power Automate is powerful, but it is not a replacement for BC-native workflow, AL extensions, or a real integration platform. Knowing the seams keeps expectations honest.

The record-based triggers fire on table events, not field-level changes by default - granular 'only when this specific field changes' logic requires conditional checks inside the flow or external business events. Performance is governed by Power Automate throttling and request limits, so high-volume BC environments (thousands of record events per hour) can hit flow-run quotas and need filtering or batching upstream.

Complex transformations, large-data migrations, and bidirectional near-real-time sync are usually better served by an AL extension, the BC API, or a dedicated integration tool. Power Automate shines at event-driven, human-in-the-loop, cross-system orchestration - not at bulk data movement or sub-second latency.

• →Record triggers are table-level; field-specific logic needs in-flow conditions or business events
• →Flow-run and request limits matter in high-volume BC environments
• →Bulk data, complex transforms, and real-time sync usually want AL, the BC API, or an iPaaS
• →Power Automate excels at event-driven, human-in-the-loop cross-system orchestration

How this compares to Odoo automation

Because Flectic implements both platforms, the comparison is worth naming directly. Odoo's native automation story is built around Automated Actions (server actions triggered by record changes), Scheduled Actions (cron-based), and Odoo Studio for no-code flows - all inside Odoo itself, with no separate licensing tier for the automation layer.

Power Automate's strength is breadth: it talks to thousands of services outside the Microsoft ecosystem and is deeply integrated into the Microsoft 365 world that many SMEs already run. Odoo's strength is depth-within-Odoo and zero incremental licensing cost for the automation engine itself, but it reaches fewer external services natively and typically needs the Odoo.sh or on-premise automation surface for advanced server actions.

The honest takeaway: neither platform's automation is strictly better. SMEs already invested in Microsoft 365 get more leverage from Power Automate's breadth; SMEs whose stack lives mostly inside Odoo get cheaper, deeper automation from Odoo's native tooling. The decision should follow the rest of the platform choice, not drive it.