Follow NovaTech
Microsoft Fabric · Unified enterprise data foundation
Sales says an active customer is one seen in 30 days. Operations says 90. Neither is wrong, but the numbers they report don't reconcile — and you have no way to decide which one to trust. That isn't a model that needs to be smarter. It's a model looking at tables nobody has agreed on. What Microsoft Fabric is for is giving every AI application one data foundation it can be trusted on.
After investing in AI, the most common frustration isn't "the model isn't good enough." It's "I don't dare act on the number it gave me."
Finance revenue, operational revenue, revenue in the report — three different numbers. Each department's extraction logic lives in its own Excel formulas and SQL, and nobody can say which is authoritative. AI only magnifies this: it will pick one, and it won't tell you which.
The warehouse takes a copy, BI takes a copy, an analyst exports another into Excel. Every move adds a version and another chance for definitions to drift. By the time AI reaches for the data, nobody can identify the source of truth.
Open data to an agent and security's first question is: whose identity is it reading as? Which regions, which customers can it see? If the answer is "all of it," the project stops there.
AI is capped by the data it can reach. Before the data foundation is fixed, more model capability only generates untrustworthy answers faster.
Fabric's capability list is long. What actually determines whether AI can use your data is these three steps — and the order can't be swapped.
All data in one lake, called directly by multiple engines, with no separate copy per use case.
Layered and traceable, so problems can be walked back
Every core metric gets an explicit business definition, formula, source, refresh frequency, owning department and permission level.
The step most often skipped, and the most expensive to skip
Turn those definitions into a business model machines can read: entity types, relationships, business rules and data bindings.
Five kinds of agent share one set of definitions
The order can't be swapped: skip step two and the semantic layer built in step three can't be trusted
Ontology's most underrated value isn't "letting AI understand data." It's making every AI use the same definitions.
Entity types · relationships · business rules · data bindings · access control
Analysts and business users
Conversational analytics
Operations teams
Continuous monitoring · alerting · triggered actions
Developers
Custom agents · tool calling
Business users / low-code
Conversational agents · process automation
Developers
Any MCP client can connect
Five consumers, one set of definitions — no re-explaining "active customer" on every platform
The agent you build in Copilot Studio, the agent you run in production on Microsoft Foundry, and the analytics agent inside Fabric can share one set of business definitions. Define once, effective in five places — no re-explaining what "active customer" means on every platform.
Microsoft's site has the full feature list. These are the four things that carry the three steps above.
One data lake across the estate — structured, semi-structured and unstructured in one store, shared and isolated across workspaces, with virtualisation cutting movement and redundancy.
Data integration, data engineering, warehousing, data science, real-time intelligence and Power BI — one platform, one chain, instead of stitching several vendors together.
Low-latency streaming analytics with device and business events ingested live, supporting monitoring, early warning and real-time decision scenarios.
Access control, sensitive data classification, data lineage, capacity and cost monitoring — one security model across the whole platform.
Wind and solar plant operating data, plus ERP finance, CRM customers, the annual budget and years of historical Excel — scattered across systems that don't talk to each other. The daily, weekly and monthly reports management sees are extracted, merged and reconciled by hand: slow, error-prone, and defined differently by each department.
Metric dictionary · DAX measures · definition governance — one set of definitions reused by every report and every agent
Natural-language Q&A · Copilot
AI agents and predictive analytics
Extended on a schedule once the foundation is in place — it doesn't all have to be built at once
Generation and grid-fed output, utilisation hours, equipment availability, curtailment, faults and downtime, site and regional rankings — drillable from group level down to a single turbine.
Revenue, cost and profit, budget attainment, project and contract margin, receivables ageing and collections, contribution by segment and subsidiary — operating metrics analysed against financial outcomes.
Sales funnel and stage conversion, win rate and cycle length, customer value and group-account analysis, forecast accuracy — across regions and team performance.
The full path from source system to report is preserved, avoiding the performance and consistency risk of reports connecting straight to production systems — and letting any problem be traced back layer by layer.
Every metric gets a definition, formula, source, frequency, owning department and permission level — settle the disagreement between people before writing code. This is the step most often skipped and the most expensive to skip.
Permissions by organisation, region, site and role: sales sees only their own customers, a site manager only their own site, sensitive financial data restricted separately.
Track consumption by workspace, heavy jobs and peak windows, so platform running cost is predictable and tunable rather than discovered on the month-end invoice.
Phase one: plant operations and existing reports → phase two: ERP finance and performance → phase three: CRM customers and sales → phase four: predictive analytics, natural-language Q&A and AI agents. Each phase closes on a business outcome that can be signed off, rather than aiming to build everything at once.
It isn't moving Excel reports into Power BI. It's using Fabric and OneLake to build one data foundation, turning operations, finance and sales data into a trustworthy, governed, reusable data asset — and laying the groundwork for the Copilot Q&A and AI agents that come next.
Data platform projects usually fail for non-technical reasons: definitions never agreed, scope never drawn, owners never confirmed. We put those before the code.
NovaTech is a Microsoft Solutions Partner working across the Microsoft stack since 2011, serving more than 1,000 enterprises from strategy through to ongoing operation.
All six Microsoft Cloud Solution Partner designations:
Advanced Specializations and dual-channel credentials:
The data platform isn't the finish line. NovaTech also delivers Copilot Studio, GitHub Copilot and Microsoft Foundry projects — we do the part that comes after the foundation is built.
A: No. In practice it's phased: connect the existing reports first and prove the definitions and data reconcile, then progressively move upstream extraction and processing into Fabric. The old systems keep running through the transition, so the business doesn't feel the switch. What to replace, where to keep raw detail, and which duplicate reports can be merged — those are conclusions the first assessment phase is meant to produce.
A: Power BI is part of Fabric, so existing reports and semantic models carry over rather than being rebuilt. The change is one layer down: instead of Power BI connecting straight to business systems or a staging database, data lands in OneLake and is layered and processed there, and reports connect to a governed model. You gain consistent definitions, controllable refresh performance and traceable lineage; the cost is doing the layering and the metric dictionary properly first.
A: A data model describes how tables are built and how fields relate. An Ontology describes the business itself — which entity types exist (site, equipment, customer, contract), how they relate, what business rules apply, and which tables those concepts bind to. The difference: a data model is for people and SQL; an Ontology is for AI. Its practical value is "define once, shared by many agents" — Fabric's analytics agent, custom agents on Foundry and low-code agents in Copilot Studio can all use the same business definitions, which is what makes their answers reconcile.
A: Row-level security by organisation, region, site and role, with object-level security added where needed: sales sees only their own customers, a site manager only their own site, sensitive financial and HR data restricted separately. The platform adds sensitive data classification, lineage tracking, refresh monitoring and access auditing. The key is aligning the permission model with the org structure — decided at blueprint stage, not retrofitted after go-live.
A: We recommend phasing. Phase one usually connects operational data and replaces the existing daily, weekly and monthly reports — fastest to show value and easiest to sign off — then ERP performance data, then CRM sales data, with prediction and AI applications last. The actual timeline depends on source interface conditions, how many years of history exist and how many reports are in scope; we commit to a schedule at the assessment stage rather than quoting a number up front.
A: Two parts. Microsoft Fabric is billed by capacity (F SKU) with Power BI licences priced separately — we recommend listing this separately in the quote so it's easy to take through your own budget process. NovaTech charges implementation and operation fees, scoped by number of sources, tables and reports and the years of history involved. Interface development on third-party systems and fees charged by incumbent system vendors are normally out of scope; we state that explicitly in the proposal to avoid disputes later.
