Business Central and Teams Integration

Of all the system pairs I have connected across twenty-two years of enterprise work, Business Central and Teams is the one where the payoff is felt fastest, because it puts the ERP where people already spend their day. A manager gets a notification in a channel, taps Approve on a card, and the purchase order releases in Business Central without ever opening the ERP. A salesperson asks about a customer in a chat and pulls the account balance straight into the conversation. This is a Microsoft-native pairing, so the tools are Microsoft's own: Power Automate, Microsoft Graph, Teams adaptive cards and the built-in Business Central app for Teams. This guide walks through how that connection actually works, and it sits inside a wider cluster of system-pair integration guides anchored by my enterprise system integrations hub.

The message up front: because both systems are Microsoft's, you almost never need generic middleware here. Power Automate is your orchestration layer, Microsoft Graph is how you post into Teams, adaptive cards are how people act, and Business Central's own APIs are the source of truth. Get the approval routing and the card design right and the rest is configuration, not code.

1. What Business Central and Teams each are, and why integrate them

Microsoft Dynamics 365 Business Central is an ERP. It runs finance, purchasing, sales, inventory and light manufacturing for small and mid-sized organisations. Its job is to execute and account for the business: turn a requisition into a purchase order, a sales quote into an invoice, and every one of those into a ledger entry. Business Central is the system of record for money and stock, built for control, approvals and auditability rather than for conversation.

Microsoft Teams is a collaboration platform. It is where the organisation chats, meets, shares files and, increasingly, does its day-to-day work inside channels and one-to-one conversations. Its job is to keep people connected and moving, and its strength is that it is already open on everyone's screen. Teams is optimised for communication and speed, not for accounting rigour.

Organisations integrate the two because the decisions that gate a business process, an approval, a question about a balance, a nudge that a KPI has slipped, happen in conversation, while the data those decisions act on lives in the ERP. Without a link, a manager has to leave Teams, log into Business Central, find the document, approve it, and switch back. With a native link, the approval request arrives in Teams as an adaptive card, the manager decides in place, and Business Central updates itself. This pattern helps wherever approvals and visibility are the bottleneck: distribution and wholesale, professional services, retail chains, construction, non-profits and any finance team that is tired of chasing sign-offs by email. If you want the underlying concepts before the specifics, my enterprise system integration explained primer covers the fundamentals that every pairing in this cluster relies on.

2. The business problems it solves

The case for integration is easiest to make by listing the specific, daily frustrations it removes. These are the symptoms I hear in almost every discovery session before a Business Central and Teams project:

• Approvals that stall. A purchase order waits for a sign-off while the approver is heads-down in Teams and never opens the ERP. Days pass, the supplier chases, and the delay was pure context-switching friction.
• Constant screen-switching. People bounce between the chat where the work is discussed and the ERP where it is recorded, and every hop is a chance to lose the thread or forget the task entirely.
• Blind spots on status. Someone asks in a channel whether an invoice was posted or a customer is over their credit limit, and the only answer is "let me check and get back to you", which often never happens.
• Email-buried notifications. Business Central alerts arrive as emails that drown in an inbox. The one that mattered, an overdue payment, a low-stock item, is three hundred messages down.
• Slow, undocumented decisions. Approvals happen verbally or over chat and then get keyed into the ERP later, if at all, with no clean audit trail linking the decision to the record.
• Poor visibility for leadership. Managers cannot see how the numbers are moving without opening a report they rarely visit, so warning signs surface late.
• Manual re-keying of decisions. A decision made in conversation still has to be typed into Business Central by hand, which is slow and a fresh chance for error.

Integration attacks all of these at once by bringing the ERP's requests and answers into the conversation and by letting a decision made in Teams write straight back to Business Central. The waiting disappears, the notification lands where it will be seen, and the decision becomes a system event with a timestamp.

3. Integration architecture

At the architectural level, Business Central and Teams connect through Microsoft's own platform rather than any third-party broker. Business Central raises an event or exposes a record through its API. Power Automate sits in the middle as the orchestration layer: it listens for the event, shapes the payload, and posts an adaptive card into Teams using Microsoft Graph. The person acts on the card, and the decision travels back the same way, through Power Automate, into a Business Central API call that updates the record. The built-in Business Central app for Teams handles the lighter path, letting people search and share record cards directly in a chat with no flow at all.

The building blocks worth naming:

• Business Central APIs are the source of truth. Business Central exposes standard REST endpoints for its entities, purchase orders, sales orders, customers, vendors, and these are how anything reads from or writes to the ERP. No decision is real until it has landed here.
• Power Automate is the orchestration layer, and for this pairing it usually replaces bespoke middleware entirely. It has native Business Central and Teams connectors, a built-in Approvals action, and it handles the transformation and routing that would otherwise need custom code.
• Microsoft Graph is the doorway into Teams. It is the API used to post messages, send adaptive cards into channels or chats, and read the context Power Automate needs. When a flow "posts to Teams", Graph is doing the work underneath.
• Adaptive cards are the interface people actually touch. They render the approval request or record summary as a rich, actionable card inside Teams, with the buttons that turn a tap into a Business Central update. The card is where integration becomes visible.
• The Business Central app for Teams is the out-of-the-box path. Installed from the Teams app store, it lets people search Business Central and paste live record cards into any conversation without a single flow. For lookup and sharing, it is often all you need.

4. Data flow: what moves in each direction

A clean integration is easiest to reason about when you split it by direction and are strict about what each side is responsible for. The two directions carry very different kinds of traffic.

Business Central to Teams (the ERP surfacing information and requests where people are):

• Approval requests for purchase orders, sales orders, payments and journals, delivered as adaptive cards the approver can act on in place.
• Notifications of events that matter, a posted invoice, an overdue payment, a document ready for review, pushed to the right person or channel.
• Record cards for customers, vendors, purchase orders and sales orders, shared into a conversation so everyone sees the same live detail.
• KPI alerts when a tracked figure crosses a threshold, so leadership hears about a slipping margin or a cash-flow dip early rather than at month end.

Teams to Business Central (the conversation acting back on the ERP):

• Approval decisions, the Approve or Reject tapped on a card, written straight back to release or block the document in Business Central.
• Comments captured alongside a decision, so the reason for a rejection or the condition on an approval is stored against the record.
• Triggered actions, a person kicking off a Business Central process from Teams, such as raising a follow-up task or updating a status, without opening the ERP.

Notice the pattern. Business Central sends requests and facts into the conversation; Teams sends decisions and actions back to the ledger. Keep that division clear and most of the design decisions make themselves.

5. Data objects exchanged

Putting the concrete objects side by side makes the contract between the two systems explicit. This is the table I sketch on a whiteboard in the first design workshop, because it forces the team to agree on what flows and who acts before anyone builds a flow.

The left column is the ERP reaching into the conversation with requests and facts. The right column is the conversation reaching back into the ERP with decisions and actions. When the team signs off on this table, arguments about "why did that flow post into the wrong channel" or "who is allowed to approve from Teams" mostly disappear, because everyone knows what each direction carries and who is on the other end of it.

6. Business process flow

The clearest way to see the integration in action is to follow one approval along its whole life and mark which system owns each step. A purchase order approval is the classic case, and it crosses the Business Central and Teams boundary twice: once out with the request, once back with the decision.

The Business Central event, a purchase order that has hit its approval threshold, is the ERP's territory. Power Automate picks it up, shapes it, and hands it to Teams as an adaptive card in front of the right approver. The moment they tap Approve, the decision crosses back over the boundary and Business Central is updated, releasing the order, with a confirmation posted back to the card so the approver sees it is done. The single most important integration event in this whole pairing is that round trip, request out and decision back, because it is what turns a stalled sign-off into a two-second tap.

7. Real-time versus batch

Not every message needs to move the instant it happens, and treating everything as real time is a common way to flood people with noise for no benefit. The discipline is to match the timing to how urgent the decision is and how much a delay would actually cost.

A caution on notification noise: the temptation to push every Business Central event into Teams the instant it happens is strong, because it feels responsive. In practice, a channel that pings for every posted document quickly gets muted, and then the approval that mattered gets muted with it. Push to instant only what genuinely needs a person now, an approval, a real alert, and batch the rest into a scheduled digest. An integration people keep switched on is worth far more than one that is technically real time and universally ignored.

8. Integration technologies and when each fits

Because this is a Microsoft-native pairing, the tooling is Microsoft's own stack, and the choice is less about which vendor than about which layer does which job. The pieces I reach for, and when:

• Power Automate. The default orchestration layer and, for most of this pairing, the whole engine. Its native Business Central and Teams connectors, plus the built-in Approvals action, cover approval routing, notifications and triggered actions with little or no custom code.
• Microsoft Graph. The API that puts things into Teams. Where you need to post a message, deliver an adaptive card to a specific chat or channel, or read Teams context, Graph is the interface, whether you call it directly or through a connector that wraps it.
• Teams adaptive cards. The actionable interface. Design the card well, the right fields, the right buttons, a comment box where a decision needs a reason, and the integration feels effortless. Design it badly and people distrust it. This is where most of the user-facing craft lives.
• Business Central APIs. The read-and-write surface on the ERP side. Standard REST endpoints for the entities you care about, called by Power Automate to fetch a record card or to post an approval decision back onto the document.
• Webhooks. Business Central can push change notifications so a flow fires the instant a document reaches an approval state, rather than polling on a timer. Webhooks are what keep the approval path genuinely instant without wasting API calls.
• The Business Central app for Teams. The zero-build option. For search, lookup and sharing live record cards into a conversation, install the app and you are done; reserve custom flows for the paths that need to write back.
• Azure Functions. The escape hatch for the rare logic Power Automate cannot express cleanly, a complex transformation or a bespoke calculation. Call it from a flow, keep it small, and do not reach for it until a low-code approach has genuinely run out of road.

My rule of thumb: the built-in Teams app for lookup and sharing, Power Automate with the native connectors for approvals and notifications, webhooks to keep the approval path instant, and Azure Functions only for the odd bit of logic that will not fit in a flow. Start low-code and add code only where you must.

9. Security

A Business Central and Teams link carries approval authority, financial figures and customer and vendor detail. That makes it a sensitive pipe, and the security thinking has to be part of the design rather than bolted on afterwards. The essentials:

• Authentication. Every call between Power Automate, Graph and Business Central is authenticated through Microsoft Entra ID using OAuth, never a shared human login. Tokens are issued to the app or the delegated user and can be revoked centrally.
• Delegated permissions. Approvals must run as the actual approver, not a shared service identity, so that the person who taps Approve is the person authorised to approve. Delegated permissions in Entra ID carry that identity through the flow to the Business Central write.
• Least privilege. The integration is granted only the scopes it needs. A flow that posts KPI digests should not hold permission to release payments. Scope each flow to its job so a leaked token has a small blast radius.
• Approval audit trail. Every decision, who approved, when, from which card, and any comment, is written back onto the Business Central record and retained. When finance asks who released a purchase order, the answer comes from the audit trail, not from a chat someone half-remembers.
• Fail safe. A card whose write-back fails must not leave the approver believing the order is released when it is not. Confirm the Business Central update before telling the person it is done, and alert on any decision that could not be committed.

10. Common challenges

The problems that actually derail Business Central and Teams projects are boringly consistent, and knowing them in advance is most of the battle:

• Approval routing. Working out who should approve what, with delegation when they are away and escalation when they do not respond, is harder than any of the plumbing. Get the routing rules wrong and cards land on the wrong person or nobody at all.
• Adaptive-card versioning. Cards evolve as you add fields and buttons, and an old card left in a channel can point at a flow that has moved on. Version the card design and the flow together, or a stale card will act on the wrong logic.
• Notification noise. Push too much into Teams and people mute the channel, at which point the integration is worse than useless because the urgent alert is silenced along with the trivial ones. Curating what deserves a ping is a constant discipline.
• Licensing. Some Power Automate patterns, premium connectors and higher run volumes, need per-user or per-flow premium licensing, and teams get caught out when a proof of concept that worked on a trial licence needs paid plans to go live.
• Identity and delegation edge cases. Approving on behalf of an absent colleague, external guests in a channel, and service-versus-user context all create tricky permission situations that have to be designed for, not discovered in production.

11. Best practices

The habits that separate an integration people trust from one they route around:

• Design approval routing first. Before any flow, map who approves what, at which thresholds, with delegation and escalation. Write it down and agree it with finance, because the routing rules, not the connectors, are what make or break this pairing.
• Keep cards focused. An adaptive card should show exactly what the approver needs to decide and nothing more, with clear Approve and Reject actions and a comment box where a reason is required. Clutter breeds distrust; clarity breeds fast decisions.
• Curate notifications ruthlessly. Send only what needs a person now, and batch the rest into a scheduled digest. Protect the signal so the channel stays unmuted and the approval that matters is always seen.
• Confirm the write-back. Never tell someone their decision is done until Business Central has actually committed it. Show the confirmation on the card, and handle the failure case explicitly so nobody acts on a release that did not happen.
• Version flows and cards together. Treat the card design and the flow behind it as one contract and version them as a pair, so a change to one never leaves the other pointing at the wrong logic.

The practitioner's insight: the single decision that most determines whether a Business Central and Teams integration succeeds is the approval-routing design, settled before any flow is built. Get finance to agree who approves what, at which threshold, with what delegation and escalation, and the flows, cards and permissions all follow naturally. Skip it, and you will spend the project firefighting cards that land on the wrong person while approvals quietly stall. Like every guide in the enterprise integrations hub, the plumbing is the easy part; the human contract underneath it is where the work is.

12. KPIs: proving it works

An integration is an investment, and like any investment it should be measured, not taken on faith. The metrics I hold a Business Central and Teams link accountable to:

• Approval cycle time. How long from a document hitting its approval threshold in Business Central to the decision being committed. Before integration it was often days of waiting; after, it should be minutes to hours.
• Approvals completed in Teams. The share of decisions made on a card versus in the ERP. A high and rising number tells you the integration is where people actually work, which was the whole point.
• Screen-switching reduced. The drop in how often people leave Teams to open Business Central for routine tasks, measured concretely. This is the friction the project set out to remove.
• Notification engagement. The rate at which posted alerts are opened or acted on rather than ignored. A falling rate is an early warning that the channel is drowning in noise.
• Return on investment. Time saved on approvals and lookups, plus fewer stalled processes, set against build and licensing cost. On this pairing the return usually shows up quickly, because the waiting it removes is so visible.

13. Industry examples

The same architecture adapts to very different sectors, with the emphasis shifting to match what each business cares about most:

• Distribution and wholesale. High volumes of purchase orders make Teams approvals a huge time saver, releasing supplier orders in seconds so stock keeps moving instead of waiting on a manager to open the ERP.
• Professional services. Project managers approve expenses, timesheets and vendor invoices from the same Teams channel where the project is run, keeping decisions close to the work.
• Retail chains. Store and area managers who live in Teams on mobile approve reorders and see KPI digests without ever logging into Business Central from the shop floor.
• Construction. Site-based staff approve subcontractor and material purchase orders from the field, with the decision and its audit trail written straight back to the ERP.
• Non-profits. Lean finance teams use Teams approvals and digests to keep tight control over spending and grants without the overhead of everyone learning the full ERP.

These are the same forces that make the neighbouring Microsoft pairings in this cluster worth reading if your estate is broader than approvals: bringing the ERP into the inbox in my Business Central and Outlook integration guide, and connecting the front office to the ledger in my Dynamics CRM and Business Central integration guide. The stack rhymes; only the surface people work on changes.

14. References

This guide leans on a small set of widely adopted, openly documented standards and platform patterns rather than reproducing any single product manual. For the interested reader, the concepts worth reading further on, by name, are:

• Microsoft Graph, the unified API surface used to post messages and adaptive cards into Teams and to read the context a flow needs.
• OAuth 2.0, the authorisation framework behind Entra ID sign-in, used to grant scoped, revocable access to Teams and Business Central without sharing passwords.
• Adaptive Cards, the open card format and schema that renders the actionable approval and record cards people tap inside Teams.
• REST and webhooks, the request-driven and event-driven patterns behind the Business Central APIs that flows read from and write back to.

Each of these is a published, openly documented standard or platform interface maintained by its respective owner or community, and the current specification is the authoritative source rather than any secondhand summary of it.

Final thoughts

Connecting Business Central and Teams is one of the highest-return integrations a mid-sized organisation can do, precisely because it puts the ERP where people already are. The waiting on approvals stops, the screen-switching drops away, and a decision made in conversation becomes a committed, audited event in the ledger. The benefits, faster approvals, less friction, notifications people actually see and decisions with a clean trail, show up quickly and are easy to measure.

The challenges are just as predictable: designing approval routing, versioning cards, curating notification noise and navigating licensing and delegation. None of them is really a technology problem, and all of them yield to the same discipline, design the human contract, who approves what and what deserves a ping, before you build the flows to serve it. Looking ahead, the direction of travel is clear: more of this handled by low-code Power Automate rather than custom code, richer adaptive cards, and AI starting to draft approvals, summarise records and surface the alerts that matter inside the conversation. Because it is all Microsoft-native, the plumbing keeps getting easier. The judgement about routing and restraint stays exactly as important as it has always been, and that is the part worth getting right.

Related reading: Enterprise system integrations hub, Enterprise system integration explained, Business Central and Outlook integration, Dynamics CRM and Business Central integration.