Microsoft Fabric Knowledge Base
OneDrive and SharePoint are where your people keep documents, spreadsheets, reports, contracts and proposals. Fabric is where your business data is brought together, cleaned and made ready for reporting and AI. They have different jobs and they work together rather than compete.
In practice, Fabric can read files that sit in OneDrive and SharePoint, for example, a budget spreadsheet or a monthly price list and combine them with data from your finance, project and CRM systems. Fabric has its own storage area called OneLake, which is best thought of as the single, governed home for business data, in the same way OneDrive is the home for documents.
- OneDrive and SharePoint: documents people create and share.
- OneLake in Fabric: business data that reporting and AI rely on.
- Fabric can pull spreadsheets from OneDrive or SharePoint into governed reporting, so the 'spreadsheet on someone's desktop' problem goes away.
Bottom line: Keep documents in OneDrive. Put the numbers the business runs on into Fabric. Fabric can read one and trust the other.
Power BI is the front window: the dashboards and reports your people look at. Fabric is everything behind the window, getting data out of your systems, cleaning it, storing it, joining it up and keeping it secure and consistent.
Most organisations do not have a Power BI problem. They have a data problem that shows up in Power BI: reports that disagree with each other, refreshes that fail, analysts rebuilding the same logic in five different files and month-end that still depends on manual spreadsheet work. Fabric fixes the cause rather than the symptom.
Power BI is included in Fabric, so this is not a replacement decision. It is a question of whether you are ready to build the foundation underneath the reports you already have.
- Buy Fabric when reports disagree, refreshes break or analysts spend more time preparing data than interpreting it.
- Stay with Power BI alone when you have one or two clean data sources and reporting is working well.
- Power BI Premium capacity (the old P SKUs) has been retired in favour of Fabric capacity, so larger Power BI customers are moving anyway.
Bottom line: Power BI shows the answer. Fabric makes sure it is the right answer, every time, without manual effort.
MCP stands for Model Context Protocol. It is simply an agreed standard for how an AI assistant connects to a system and is allowed to ask it questions or do work on it. Think of it as a universal plug, the USB-C of AI connections.
Before MCP, every AI-to-system connection was custom-built and expensive to maintain. With MCP, an assistant such as Copilot can connect to Fabric, a finance system or a CRM through a standard interface and the connection respects the same permissions your staff already have.
For an executive, the commercial point is this: MCP lowers the cost and risk of connecting AI to your business systems, and it avoids locking you into one vendor's proprietary integration.
Bottom line: MCP is a standard plug that lets AI assistants safely talk to your systems. It reduces integration cost and keeps you out of lock-in.
Usually you would not. Microsoft already provides MCP servers for Fabric and Copilot and other assistants can use them to search your Fabric environment and work with your data using your existing permissions. For most organisations that is enough.
You would consider building your own when you have a system or a business process that no standard connector covers, for example, a bespoke industry application, a proprietary pricing engine or a specialist operational system unique to your sector. In that case a custom MCP lets AI reach that system in a controlled way.
Treat a custom MCP as a project with a business case, not a default step. It needs ownership, security review and ongoing maintenance.
- Start with what is provided — the standard Fabric connections cover the common cases.
- Build your own only when a genuinely unique system holds data that materially changes a decision.
- Always attach a business case: what decision improves, by how much, and who owns it afterwards.
Bottom line: Fabric gives you the standard connections out of the box. Build a custom one only when a unique system is blocking a valuable outcome.
Fabric is bought as a shared pool of computing capacity rather than per person, so the value comes from using that pool well and from retiring cost elsewhere.
The organisations that get the best return do four things. They start small and scale deliberately. They pick two or three high-value use cases rather than boiling the ocean. They shut down or consolidate the tools and manual processes Fabric replaces. And they measure the benefit in business terms, hours saved at month-end, margin recovered on under-performing clients or products, working capital released.
- Start on the smallest capacity that does the job and scale up when the workload proves it.
- Commit to reserved capacity once your usage is predictable, a one-year reservation is materially cheaper than pay as you go.
- Pause or scale down non-production environments outside business hours.
- Decommission the licenses, legacy databases and manual reporting effort that Fabric replaces, and count that saving.
- Set a small number of measurable outcomes up front so the investment can be judged.
Bottom line: Right size first, reserve capacity once usage is predictable and make sure the old cost goes away.
Bill shock happens when capacity is bought too large, left running when nobody is using it or consumed by AI features with no owner and no limit. All three are controllable.
Fabric gives you a usage dashboard that shows which workloads are consuming capacity. Set a budget, review consumption monthly in the same way you review any other operating cost and make someone accountable for it.
On AI specifically, the discipline is the same as any other spend: approve use cases, not experiments. AI usage that is billed on consumption should be tied to a purpose, a report summary that saves an analyst an hour, a forecast that improves ordering, rather than open-ended exploration by anyone who finds the button.
- Set spending limits and alerts before you turn anything on, not after the first invoice.
- Give one named person ownership of capacity consumption and review it monthly.
- Approve AI use cases with an expected benefit; retire the ones that do not deliver.
- Pause development and test environments when they are not in use.
- Review scheduled data refreshes, refreshing hourly when the business decides weekly is pure waste.
Bottom line: Set a budget, name an owner, review monthly and only let AI run where there is a named benefit.
Copilot Cowork is Microsoft's agentic assistant. Rather than answering a question, it takes a task and carries it out across your Microsoft 365 environment, preparing documents, drafting communications, pulling together briefings, with you approving the actions before they happen.
Fabric and Cowork solve different halves of the same problem. Fabric makes the numbers trustworthy. Cowork turns those numbers into work that actually gets done: the board pack, the client update, the weekly exception report that someone currently assembles by hand.
Use Cowork alongside Fabric when the bottleneck is not knowing the number, but the human effort required to package and distribute it.
- Good fit: recurring reporting packs, executive briefings, client updates, month-end commentary.
- Poor fit: one-off analysis, or anything where the underlying data is not yet trustworthy.
- Sequence matters: get the data foundation right in Fabric first, then let Cowork do the assembly and distribution.
Bottom line: Fabric makes the number trustworthy. Cowork removes the manual work of turning it into a document, a pack or an update.
AI is only as good as the data it can reach. Most failed AI initiatives fail for an unglamorous reason: the information was scattered across systems, inconsistent, out of date or ungoverned, so nobody could trust what the AI produced.
Fabric addresses exactly that. It brings data from your finance, operations, customer and project systems into one governed place, applies consistent definitions and controls who can see what. Once that is in place, AI has something reliable to work from and so do your people.
It also means you only have to solve the data problem once. The same foundation serves your dashboards, your forecasting, your Copilot experiences and whatever AI capability arrives next year.
- One governed source of business data instead of competing spreadsheets.
- Consistent definitions, so 'revenue' or 'active client' means the same thing everywhere.
- Security and access control applied once and inherited by every tool on top.
- A foundation that outlives any single AI product decision.
Bottom line: AI fails on bad data, not bad models. Fabric is the work you have to do anyway before AI can be trusted.
Yes and in most organisations they become more valuable, not less. What changes is what they spend their day on.
Today, a large share of analyst time goes on collecting data, reconciling it, fixing spreadsheets and rebuilding reports. That is the work Fabric removes. What remains is the work you hired them for: interpreting what the numbers mean, challenging assumptions, spotting risk early and advising the business.
The realistic outcome is not fewer analysts. It is the same analysts producing several times the insight, and finance and operations leaders getting answers in hours rather than weeks.
- Before: most analyst time on data preparation, a small slice on insight.
- After: most of the time on insight, advice and decision support.
- Capacity is multiplied rather than headcount reduced which is usually where the commercial return actually comes from.
Bottom line: You still need analysts. Fabric changes them from data collectors into decision advisers.
Not necessarily to get started but developers can significantly increase the value you create. Fabric provides an MCP capability that gives AI a standard, governed way to work with your data. This reduces the need for developers to spend time building and maintaining basic connections, so they can focus on higher-value business improvements.
Developer skills then become a force multiplier. With Fabric supplying well-structured, governed data, developers can fully leverage AI to build agents, mini apps and automated workflows tailored to how your business operates.
The sequence matters: establish trustworthy data in Fabric first, use the built-in MCP capability to make that data accessible safely, then apply developer expertise to turn it into practical tools that improve decisions, customer experiences and operations. AI solutions work best when the data behind them is reliable.
- Fabric MCP: standard, governed access to data without rebuilding every AI connection from scratch.
- Developer focus: spend less time on plumbing and more time improving products, processes and customer outcomes.
- Developer leverage: use AI to build business-specific agents, mini apps and automations.
- Trusted data first: agents and apps are only as useful as the quality, consistency and governance of the data they use.
Bottom line: No permanent developer required. Get specialist help to build the foundation, then run it with the people you already have.
It solves the gap between having data and being able to act on it. The symptoms are familiar: two reports that disagree, a month-end that takes a fortnight, decisions made on gut feel because the numbers arrive too late, and nobody able to answer a simple question without a week of spreadsheet work.
Fabric gives the business one trusted view of performance, refreshed automatically, that everyone works from.
Bottom line: It turns scattered, argued-over data into one trusted view the business can act on.
No. The common misconception is that Fabric is about volume. For most mid-sized organisations the driver is complexity, not size — information spread across finance, CRM, project, payroll and operational systems that will not join up.
Entry-level capacity is modest enough that a business with a few hundred staff can start sensibly, and you scale as the value proves itself.
Bottom line: The trigger is fragmented systems, not terabytes. Mid-sized businesses often get the fastest return.
A realistic first 90 days delivers a working foundation and one or two visible wins — typically a consolidated executive dashboard that replaces a manual pack, and the retirement of a recurring spreadsheet process.
What you should not expect in 90 days is every system connected or advanced forecasting in production. Those come once the foundation is proven.
- Weeks 1–4: agree the priority questions, connect the first two or three data sources.
- Weeks 5–8: build the trusted data model and first executive dashboard.
- Weeks 9–12: retire a manual process, measure the time saved, agree the next use case.
Bottom line: Expect a working foundation plus one or two visible wins — not a finished data platform.
Build it on three lines: cost removed, time released and decisions improved. Cost removed is the licences, legacy tools and duplicated systems that go away. Time released is the hours currently spent on manual reporting and reconciliation, valued at a loaded hourly rate. Decisions improved is the hardest to quantify but usually the largest — margin recovered, stock reduced, risk caught earlier.
Keep the case to one page and to three or four measurable claims. A business case with twenty soft benefits does not get approved.
Bottom line: Cost removed, time released, decisions improved — three or four measurable claims on one page.
The cost of inaction is rarely a dramatic event. It is a slow accumulation: manual reporting effort that grows with the business, decisions made late, staff frustrated by systems that do not talk, and an AI agenda that cannot start because the data is not ready.
The competitive risk is that peers who fix their data foundation now will be making faster, better-informed decisions within a year.
Bottom line: Nothing breaks. You just keep paying in manual effort, late decisions and a stalled AI agenda.
No. Fabric does not run your business processes — it reads from the systems that do. Your finance system still does finance, your CRM still manages customers.
What Fabric replaces is the layer of spreadsheets, manual extracts, standalone databases and reconciliation work that currently sits between those systems and your decisions.
Bottom line: Your core systems stay. Fabric replaces the spreadsheets and manual effort sitting between them.
Fabric is priced on capacity, not per person. You buy a pool of compute — the F SKUs, which start small and double in size at each step — and every Fabric workload draws from that same pool.
There are two other components to budget for: storage in OneLake, billed per gigabyte and comparatively inexpensive, and per-user Power BI licences for people who publish or share content.
- Capacity — the main cost, scalable up or down, and pausable.
- Storage — billed separately, commodity rates.
- Per-user licences — for publishers; at larger capacity tiers, report viewers no longer need their own licence.
Bottom line: One shared pool of capacity, plus storage, plus licences for publishers. Not a per-user platform.
Yes, and you should. Capacity can be increased, decreased or paused, so you are not locked into a size you guessed at before you understood the workload.
The recommended approach is to run on a small capacity for the first few months, measure actual consumption, then commit to a reserved capacity at the level your usage genuinely supports.
Bottom line: Start small, measure real usage for a few months, then commit at the level the evidence supports.
Pay-as-you-go while you are learning what you need, because it can be paused and adjusted freely. Reserved capacity once your usage is predictable, because a one-year commitment is significantly cheaper than pay-as-you-go for the same capacity.
Many organisations run a hybrid: reserved capacity for the steady baseline, pay-as-you-go for peaks and development.
Bottom line: Pay-as-you-go while you learn. Reserve the predictable baseline — the discount is substantial.
The costs that surprise people are rarely the capacity itself. They are the change costs around it: data cleanup, people's time during migration, training, and running old and new reporting in parallel for a period.
There is also the cost of not decommissioning. If the legacy tools and manual processes stay in place alongside Fabric, you have added cost rather than replaced it.
- Data cleanup and one-off migration effort.
- Internal time — your people are part of the project cost.
- Training and adoption support.
- Parallel running while confidence is built.
- The saving you never realised because the old process was never switched off.
Bottom line: The surprises are change costs and failure to decommission — not the capacity bill.
Time savings usually appear within the first quarter, because manual reporting is the easiest cost to remove. Decision-quality benefits — better margin management, better forecasting — typically show over two to four quarters as people learn to trust and use the data.
Set the expectation accordingly. Quick wins fund confidence; the larger return comes from changed behaviour, which takes longer.
Bottom line: Time savings in the first quarter. The bigger decision-quality return over two to four quarters.
It carries forward. Your reports, datasets and the skills your team has built all continue to work — Power BI is part of Fabric, not a competing product.
Organisations that were on Power BI Premium capacity are moving to Fabric capacity regardless, since the older Premium capacity model has been retired.
Bottom line: Nothing is thrown away. Power BI is part of Fabric, and Premium customers are migrating anyway.
Not for everyday Copilot use on documents, email and meetings — that works on the content already in Microsoft 365.
You do need something like Fabric when you want AI to answer questions about business performance: margin by client, stock position, utilisation, forecast accuracy. Those answers come from data in your business systems, and AI can only be trusted with them if that data has been brought together and governed.
Bottom line: Copilot on documents needs no Fabric. Copilot on your business numbers does.
Fabric applies your existing Microsoft security and identity controls, so access follows the permissions your people already have. Sensitivity labels, auditing and data protection policies carry through.
You also control where your data is physically stored, which matters for Australian data residency and for any regulatory or contractual obligations you carry.
- Access governed by existing identity and permissions.
- Data residency selectable by region.
- Audit trails and sensitivity labelling carried through from Microsoft 365.
Bottom line: It inherits the security model you already run, with regional control over where data lives.
Governance sounds bureaucratic but comes down to three practical questions: who can see what, what each measure officially means, and who decides when either changes.
Ownership should sit with the business, not IT. A small data governance group — typically finance, operations and IT — meeting monthly is usually enough for a mid-sized organisation.
Bottom line: Who sees what, what the numbers mean, who decides. Owned by the business, supported by IT.
It almost certainly is not perfect, and that is fine. Waiting for clean data is the most common reason data projects never start.
The practical approach is to pick one business question, fix the data needed to answer it well, and move on. Quality improves use case by use case, and the act of putting data in front of executives is what surfaces the errors worth fixing.
Bottom line: Nobody's data is clean enough. Fix it one valuable question at a time.
Both, but in sequence. Reporting tells you what happened and is where the early value sits. Forecasting and prediction — demand, cash, utilisation, churn risk — become genuinely reliable once the underlying data is consistent and historical.
Most organisations should earn the right to forecast by first getting the reporting foundation trustworthy.
Bottom line: Reporting first, forecasting second. Prediction is only as good as the history behind it.
It connects to them. Fabric has a wide range of built-in connectors for common business systems, databases, cloud services and files, and it can also work with data that stays where it is rather than being copied.
Being a Microsoft platform does not mean a Microsoft-only data estate. Most Fabric implementations pull from a mix of vendors.
Bottom line: Non-Microsoft systems connect fine. A mixed data estate is the normal case, not the exception.
Sponsorship should sit with a senior business leader — usually the CFO or COO — because the value is measured in business outcomes, not technical delivery. IT owns the platform; the business owns the questions, the definitions and the benefits.
Projects that are owned solely by IT tend to produce technically sound platforms that nobody uses.
Bottom line: Business leader owns the outcomes, IT owns the platform. IT-only ownership is the classic failure mode.
Less than most people assume. You need someone who understands the business questions deeply, someone comfortable building reports, and a nominated owner for governance and cost.
Deep technical skills are best accessed through a partner until the volume of work justifies hiring them.
Bottom line: Business understanding, reporting capability and a named owner. Everything deeper can be partner-supplied.
Adoption follows trust and relevance. Two things drive it: the numbers must match what people already believe to be true, and the new way must be clearly easier than the old way.
Switch off the old report once the new one is trusted. As long as the spreadsheet still exists, people will keep using it.
- Involve the people who will use the reports in designing them.
- Reconcile against the existing numbers publicly so trust is earned.
- Set a date to retire the old process and hold it.
- Train in the context of real work, not as a generic tool session.
Bottom line: Earn trust by reconciling to what people already know, then switch the old report off.
Almost never the technology. The recurring causes are: no clear business question at the start, too many use cases attempted at once, no named business owner, no decommissioning of what it replaced, and no measurement of benefit.
Each of these is a governance and leadership issue, which means each is preventable.
Bottom line: Projects fail on scope, ownership and follow-through — not on the platform.
Most mid-sized organisations are best served by a partner for the build and their own team for the run. The build requires skills you will use intensively for a few months and rarely afterwards; the run requires business knowledge you already have.
Whichever model you choose, make sure the partner leaves you with documentation, working knowledge and the ability to make changes yourself.
Bottom line: Partner to build, your team to run — and insist on a handover that leaves you self-sufficient.
Pick the one that meets three tests: a senior leader genuinely cares about it, the data needed is reachable within a few weeks, and the benefit is measurable.
Resist starting with the hardest problem simply because it is the most valuable. Early credibility is worth more than early ambition.
Bottom line: Someone senior must care, the data must be reachable, the benefit must be measurable.
A defensible roadmap has three phases: prove, extend, embed. Prove takes one quarter and delivers a trusted foundation with a visible win. Extend takes two quarters, adding data sources and use cases while retiring manual processes. Embed takes the final quarter, moving from reporting into forecasting and AI-supported decisions.
Review the business case at each phase gate. If the benefit is not showing, change course rather than continuing on momentum.
Bottom line: Prove in one quarter, extend over two, embed in the fourth — with a benefit review at each gate.
Measure it as you would any operating investment. The strongest measures are practical: days to close the month, hours spent on manual reporting, number of competing versions of a key number, and the proportion of leadership decisions made with current data.
Agree three or four of these before you start and baseline them. Retrospective measurement is never convincing.
- Days to close and report.
- Manual reporting hours removed per month.
- Number of conflicting versions of key measures.
- Legacy tools and licences decommissioned.
- A named commercial outcome — margin, stock, utilisation or working capital.
Bottom line: Baseline three or four practical measures before you start. Retrospective benefit claims never convince.
Three steps. First, write down the five questions your leadership team cannot answer quickly today. Second, identify which systems hold the data behind them. Third, run a short discovery to size the effort and build the business case.
Discovery is typically a half-day to a day of structured work and gives you enough to make an informed investment decision rather than an act of faith.
Bottom line: List the five questions you cannot answer today, find out where that data lives, then run a short discovery.
