Most "BI for Business Central" conversations end the same way: with Power BI. The customer's already paying for it, Microsoft pushes it as the default, and there's a partner ecosystem ready to build dashboards in it. So the obvious answer is to use it.
We kept ending up in the same conversations: the customer wanted dashboards, the customer was already paying for Power BI, and yet we kept walking out of the room having recommended against it. So when we sat down to build SourceForge Insight — our Role Center charting dashboard for BC — we started by writing down why we kept rejecting the obvious answer.
What Power BI is good at — and what it's heavy for
Power BI is the right tool when you have a real BI workload: multi-source joins, complex DAX measures, semantic-layer modelling, scheduled refreshes, drill-paths across hundreds of dimensions, distribution to non-BC users who need a polished SaaS report experience. For those use cases, nothing else is close.
For a different question — "I want a few charts at the top of my BC Role Center so I can see my numbers when I open BC in the morning" — Power BI is heavy in five different ways.
Heavy in tenancy. Power BI lives in a separate Microsoft tenant from BC. Sharing data between them means dataflows, gateways, service principals, and a regular conversation with your security team about which fields cross the boundary. For a BC-only customer who's not running any other Microsoft analytics, this is a lot of infrastructure to stand up for a few charts.
Heavy in licensing. Power BI Pro is per-user per month, on top of the BC licence. For a customer with thirty BC users who all want to see charts on their Role Center, that's a real recurring spend.
Heavy in latency. Power BI refreshes on a schedule. The BC data the user is looking at on the Role Center and the Power BI numbers above it are out of sync by however long it's been since the last refresh — typically tens of minutes to hours. Users notice. They ask. Trust degrades.
Heavy in deployment. Building a useful Power BI dashboard for BC is a project. Connectors, datasets, measures, visuals, sharing. Six weeks if you have a partner who's done it before. Three months if you don't.
Heavy in residency. For customers in regulated industries — financial services, healthcare, defence contractors — having BC data leave the BC tenant and land in a Power BI workspace is a conversation with compliance every time. Some categorically can't do it.
What we built instead
Insight is a charting dashboard that ships as an AL extension and renders directly inside the BC Role Center, above the standard Cues. No second tenant. No additional licence per user. No scheduled refresh. No outbound HTTP. Zero data leaves the BC tenant — both chart libraries (ApexCharts and Chart.js, both MIT-licensed) ship as embedded control-addin resources rather than CDN loads.
The decisions that made this work, in rough order of importance:
Sit above the Cues, not next to them. We never modify the standard BC Role Center. Insight adds a new section above the Cues using additive Page Extensions with addfirst. Disable Insight for a user and the Role Center returns to vanilla with zero residue. The standard Cues, Activity Groups and Wave-style navigation are exactly as Microsoft shipped them.
One normalised series contract, two renderers. Providers (curated and generic) emit only data points and light metadata. A serializer is the single writer of the normalised series JSON. A JavaScript dispatcher in the control add-in is the only thing that knows about ApexCharts vs Chart.js. Switching a widget from one library to the other is a metadata change with no re-compute — and if a third library ever needs to ship (say, a more specialised mapping engine), the change is local to the renderer side.
Page Background Tasks for compute. Every widget runs in a read-only child session, so the Role Center stays interactive while widgets are still rendering. Cache hits skip the task entirely. A failing widget — bad query, deleted base table, missing permission — is isolated and shows a clear in-tile message rather than breaking the Role Center.
Permission-true reads, then governance on top. The generic provider uses RecordRef and FieldRef, so a user who can't read a table in BC can't put it on a dashboard. Above BC's standard permissions, we add an administrator allowlist (only tables the admin enables show up in the Widget Builder) and a sensitive-field exclusion list (payroll fields on Employee, for example, hidden even where the user has table read permission). Failures fail safely as permission-denied tiles, not as data leaks.
Curated catalog plus generic builder. Eighty-three sources ship in the catalog at install — sales / AP / AR / inventory trends, top-by-dimension breakdowns, KPIs over stable base tables. A separate generic builder lets power users add their own widgets against any allowlisted table. Both flow through the same RecordRef aggregator, which keeps the engine small and the behaviour consistent.
The "above the Cues" framing matters
The single thing that gets the most positive reaction from customers is the placement decision. Power BI dashboards sit somewhere else — in another browser tab, in a Teams channel, embedded in a Workspace. Users have to remember to look at them. Insight is in the same place the user already opens every morning to start their work. The numbers are there when BC is there.
The compromise we made for this is real: we can't do what Power BI does at scale. Insight is great for forty widgets across eight Role Centers; it's not the tool to build a thousand-measure semantic layer over your entire ERP. We're explicit about this in conversations. If a customer needs full BI, they should buy Power BI. If they need a few charts that always know what their BC data says right now, they should buy Insight. The two tools coexist; they don't compete for the same job.
Why "no outbound calls" matters more than people expect
Five years ago, "no outbound calls" was a feature for a small slice of customers — defence, healthcare, banks. We assumed Insight would land there.
What we've actually found is that the zero-outbound posture is what unlocks the fast deployments. Without an outbound HTTP boundary, there's no firewall conversation, no proxy whitelist, no certificate review. The IT security team's review for Insight is "does it call out? no? install it." For Power BI the review is meaningful and rightly so; for a charting layer on a Role Center, it's overkill. Cutting the deployment from "six-week security review followed by six-week build" to "one-day install followed by one-week tuning" is the actual product story.
We didn't intend to build a security-first product. We intended to build a fast-to-deploy product, and the way to do that turned out to be making the security review trivial.
What this says about defaults
There's a pattern across our BC extension line: when there's an obvious default (Power BI for BI, scanners for warehouse, scheduled-refresh for analytics), we ask whether the default is the right answer for most of the customer's actual jobs, or just the marketing-easy answer. The answer is usually that the default is the right answer for the top 10% of jobs and a heavy answer for the bottom 90%. So we build for the 90% and let the 10% keep using the default. Insight is what that looks like for dashboards.