A purchase order for $18,400 sits in approval limbo for six days. Production is waiting on the materials it covers. Nobody in finance is refusing to approve it — nobody can find it. The Power Automate flow that used to route approvals like this into a Teams channel was built fourteen months ago by an ops analyst who left the company in March. She never documented which SharePoint list it watched, which connector account it ran under, or what was supposed to happen when a step failed. It worked, until it didn't, and now three people are guessing.
This is not a rare failure. It's the predictable second act of the most common fix for a real gap in Business Central. IntelliconnectQ builds OpsGrid, a decision infrastructure layer for Business Central, so this comparison has a stake in the outcome — the limitations described in BC's native approvals and the costs of the Power Automate workaround below are documented platform behavior, not invented for the pitch.
Business Central ships with a native Approvals feature: workflow rules that route requests — purchase orders, sales credit memos, general journal batches — to specific approvers based on setup tables and approval hierarchies configured once. It handles a straight chain well: request comes in, goes to approver A, escalates to approver B past a set amount. What it doesn't do natively is post that request as an actionable card inside Microsoft Teams, where most BC operations teams already spend their day. Approvers get a system notification or an email, generated by a background job — the Job Queue — that has to be running on schedule for any of it to fire.
Where Business Central's native approval engine actually breaks down
Three limits show up consistently once a BC operation grows past a handful of approval chains:
Power Automate closes the gap — at a real cost
Power Automate is Microsoft's own suggested path for exactly this problem: build a flow that watches for a BC approval event and posts it into Teams or Outlook with proper routing logic. It works. It's also where the second failure mode starts.
Not an anti-Microsoft argument. Power Automate is a legitimate, widely used pattern for this exact gap. The trade-off below is about what happens after the flow is built, not whether the tool itself works.
Two costs show up once the flow is live. The first is licensing: Power Automate's premium connectors and per-flow run limits carry per-user cost that scales with headcount — the same licensing-cost pattern already documented in IntelliconnectQ's lifecycle automation case study, where a client eventually moved off Power Automate at scale specifically to remove that cost. The second is continuity: a flow built by one person, in their own tenant context, with no peer review and no documentation, is a single point of failure that doesn't announce itself as one. It looks like infrastructure. It's actually one person's tribal knowledge wearing infrastructure's clothes.
| Dimension | BC Native Approvals | Power Automate | OpsGrid |
|---|---|---|---|
| Teams approval card | No | Yes, custom-built | Yes, native |
| Setup effort | Included, config only | Flow-builder time, ongoing maintenance | Guided setup, ~2 weeks |
| Routing changes | Needs a consultant or developer | Flow edits — needs the original builder | Configurable, no code |
| Per-user licensing | Included in BC | Premium connector cost scales with users | No per-user approval license |
| Notification reliability | Depends on Job Queue running | Depends on connectors staying authenticated | Monitored, alerts on failure |
| Audit trail | BC change log only | Flow run history — rarely reviewed | Signal, approver, action, timestamp — one record |
| Continuity when the builder leaves | N/A — no builder | High risk — undocumented, single-person knowledge | Owned by the platform, not a person |
The workaround inherits the governance problem it was built to fix
Business Central's native gap is that no system owns making sure the right person sees an approval fast. Power Automate's gap, once the flow is live, is that no one owns knowing how it actually works. Same shape of problem, one layer over. Fixing the visibility gap with a workaround that has its own undocumented single point of failure doesn't close the governance gap — it moves it somewhere harder to see, until the day someone goes looking for a SharePoint list that only existed in one person's head.