Could Power BI and Copilot just do this instead?
For a lot of what they're built for, honestly — yes. This page is a fair account of what Power BI, Fabric and Copilot do well, what the capacity model actually costs once your report viewers are counted, and where a governed layer sits alongside them rather than instead of them.
What Fabric and Copilot are genuinely good at
If your business already runs on the Microsoft stack — Microsoft 365, Dynamics, Azure — Fabric is a serious, capable platform, not a cut-down add-on. It brings data engineering, warehousing, real-time analytics and Power BI reporting under one shared capacity, on one bill, instead of stitching several Azure services together yourself. Copilot inside it can draft DAX, summarise a report in plain English, and generate a first-pass visual faster than most people would build one by hand.
None of that is a knock against Microsoft. It's a genuinely strong platform for what it's built to do: reporting and analytics on data that's already inside, or easily connectable to, the Microsoft ecosystem.
The capacity mechanism, and where Microsoft actually moved the goalposts
Fabric is priced by capacity, not by seat. You buy an "F-SKU" — F2, F4, F8, up through F64 and beyond — and that capacity powers every workload your organisation runs on it. Two things about this mechanism regularly cause confusion, and it's worth being precise about both, because Microsoft itself changed one of them fairly recently.
Copilot access is no longer gated behind F64. For a period, Copilot and Fabric's other AI features were only available on F64 capacity and above — a real barrier for a smaller organisation. Microsoft removed that restriction during 2025: general Copilot and AI capabilities became available from F2 upward, and the separate billing mechanism for Copilot usage, Fabric Copilot Capacity, later dropped to the same F2 floor. If your understanding of Fabric is "you need F64 just to get the AI features," that was true once and no longer is — worth crediting Microsoft for lowering that particular barrier.
F64 still matters, but for a different reason: who has to pay to view a report. Per Microsoft's own Fabric pricing documentation, publishing to Power BI always requires a Pro licence, currently around £12.50 per user per month. Below F64 capacity, everyone who simply views a published report needs that same licence. At F64 and above — described in Microsoft's own materials as the equivalent of a legacy Power BI Premium P1 capacity — report viewers no longer need an individual Pro licence at all. That's the real threshold, and it's a licensing-cost question, not an AI-access one.
What that means in pounds, for a business your size
Independent UK pricing guides put F64 at roughly £6,400–£6,750 a month pay-as-you-go, or roughly £3,850–£4,200 a month on a one-year reserved commitment — figures that vary a little by source and by exactly when they were checked, which is exactly why we're citing a range rather than a single number, alongside Microsoft's own Azure Fabric pricing page for the mechanism itself.
Set that against individual Pro licences at roughly £12.50 per user per month, and the arithmetic does itself: at the lower end of that reserved range, F64 pays for itself against Pro licences somewhere around 300 to 340 report viewers. That's not a rounding exercise — it's roughly where several independent UK pricing breakdowns place the same crossover, working from their own figures.
Which is the actual answer to "should we go to F64": for a business with 25–120 staff, the honest answer is almost always no. F64 is priced, and was designed, for organisations with hundreds of report viewers. A business your size sits well below that crossover — individual Pro licences for the handful of people who actually publish reports is very likely the more sensible reading of Microsoft's own pricing, not a large capacity commitment.
Where a governed layer sits alongside this, not instead of it
None of this is an argument against Power BI. If your business already has, or plans to build, Power BI reporting, there's no reason Sysgraft would ask you to give that up — a graft can sit alongside it rather than replace it.
What Power BI and Copilot work with is the data you connect to them. What a graft adds is getting your data into that joined, reasoned-over state in the first place — across your ERP, your CRM and the spreadsheets that never made it into either — plus a record of what any AI action touched once it's joined. That's a different layer of the problem to the one Power BI and Fabric are solving, which is exactly why the two aren't in competition so much as answering different questions.
Fair comparison, honest arithmetic.
We'd rather you rule Power BI in or out on real numbers than on a sales pitch — ours or Microsoft's. The snapshot tells you where your actual constraint sits, whichever way that arithmetic points.