Microsoft Fabric for FMCG Companies: What to Know Before You Buy

Microsoft Fabric is now the default proposal for that argument in the Microsoft-centric mid-market — an FMCG business on SAP or Dynamics 365, already paying for Power BI, already committed to Azure. What the proposals skip is a straight answer to three questions: what does this genuinely fix, what does it not fix, and what has to be true in my distributor network for it to pay back.

This is a pre-purchase evaluation, not a product tour. The symptoms are always the same: numeric distribution two teams calculate differently, a promotion whose real return is known six weeks after the money is spent, and a demand forecast built on primary sales — the number furthest from consumer demand.

Microsoft Fabric is a single SaaS analytics platform combining data integration, a Delta Lake storage layer called OneLake, Spark engineering, a warehouse, real-time intelligence and Power BI, billed on one shared capacity. For FMCG, its value is holding ERP primary sales, distributor secondary sales, stock and outlet data in one governed model rather than five disconnected extracts.

The commercially important word is one: what changes is the number of contracts, integration points and reconciliation jobs needed to get sales, supply chain and trade finance querying the same table. The engineering underneath — SKU harmonisation across ERP material codes and distributor item codes, outlet deduplication, unit-of-measure conversion — is where these builds actually run long. Architecture rarely is.

Each source is defensible alone. Together they cannot answer a cross-cutting question.

Fabric genuinely solves the technical half: ingestion without a tool per source (mirroring replicates SQL Server, Oracle, SAP and Snowflake into OneLake as Delta, with free replication compute and one free terabyte per capacity unit); reusing data you already hold (OneLake shortcuts point at S3, ADLS Gen2 and Iceberg without copying); reporting without a refresh window (Direct Lake reads Delta through metadata framing); a declarative transformation layer (Materialized Lake Views with data quality constraints); and a route from insight to action (Activator triggering Power Automate flows and Teams messages).

Fabric does not solve: a distributor who does not upload — it shows the gap precisely but does not close it; a missing SKU and outlet mapping — no feature infers which distributor item code matches which ERP material code; scheme history never captured in structured form — promotional uplift modelling needs start dates, mechanics and target SKUs, and if those live in approval emails, the model has nothing to learn from; and two versions of the truth — keep the old secondary sales report live and you have bought a platform and kept the argument.

Four preconditions determine payback:

• Upload compliance, measured. Produce a table by distributor, by week, over six months: expected uploads versus received. Below ~80% completeness, this is a commercial conversation — usually tied to scheme payout terms — running alongside the build, not after it.
• An owned SKU mapping. A versioned table with a named owner, covering promotional pack codes mapped back to base SKUs. Not a spreadsheet on a sales-ops laptop. Every estate that skipped this rebuilt it within six months.
• Outlet mastering with an owner. Numeric distribution is the count of outlets billing your product. If the same kirana store exists three times across distributor systems, that board metric is arithmetically wrong. Deduplication is a running process with survivorship rules, not a migration task.
• Scheme and claim history. Trade spend is one of the largest controllable P&L lines and the least well recorded. Without structured capture, promotional ROI is off the table in phase one regardless of platform — say so in the business case rather than discovering it in month four.

Fabric is sold as F SKUs from F2 to F8192, billed per second on Azure with no commitment, or discounted through one- and three-year reservations. The decision that dominates mid-market economics is F64: at F64 or larger, free-licensed viewers can consume Power BI content, while below F64 every viewer needs a Pro or PPU licence. That threshold is the whole commercial argument in FMCG, because FMCG has a lot of viewers — regional and area sales managers, key account managers, distributor-facing staff. Run the arithmetic both ways.

Four further facts that change mid-market planning. Capacity is pausable — F SKUs pause and resume, suiting non-production capacities. Throttling is progressive, not a cliff — Fabric smooths interactive operations over 5–64 minutes; once smoothed usage borrows more than 10 minutes of future capacity, interactive jobs are delayed 20 seconds, past 60 minutes rejected. Surge protection belongs in week one. And region matters in the GCC and India — UAE North supports all workloads while UAE Central is Power BI only; Central and South India support all workloads while India West is Power BI only. If Copilot is in the proposal, it needs an F2 or higher paid SKU and is unavailable on trial SKUs.

The last two separate a partner from a supplier.

Do not buy yet if: secondary sales data barely arrives — below ~50% upload compliance, spend the money on distributor commercial terms and a lightweight collection mechanism first. The ERP is being replaced within nine months — build against the system you are keeping. Nobody senior will switch off the old report — a sponsorship problem, not a technical one, and the most common cause of stalled programmes. The real requirement is better reporting on ERP data alone — a well-built Power BI semantic model on existing licences costs a fraction of a capacity. Or there is no named internal owner after go-live — outlet masters drift, pipelines fail silently, and reports stop being trusted within two quarters.

Mirrored data is read-only in Fabric — corrections happen at source or in a deliberate override table with its own audit trail; teams planning to "fix it in the lakehouse" find out late. Direct Lake guardrails vary sharply by SKU — on F2–F8, a model is capped at 300 million rows, 10 GB and 3 GB memory; F64 raises that to 1.5 billion rows. Direct Lake on OneLake does not fall back, so exceeding a guardrail fails the refresh; Direct Lake on SQL falls back to DirectQuery, including when SQL-based RLS applies — a common cause of "the report got slow after go-live".

Fabric data agents are narrower than the demo suggests — English only, read-only, five sources maximum, 25 rows by 25 columns. Capacity is shared and workloads compete — a month-end Spark rebuild, an ad-hoc Copilot session and a live regional review draw on the same CUs. Outlet mastering never finishes — field staff create outlets daily. And none of this fixes a distributor relationship: the most common root cause of poor secondary sales visibility is commercial.

Before evaluating a single proposal, answer four questions this week:

• Over the last six months, what percentage of expected distributor uploads actually arrived, by distributor?
• Can every distributor item code be mapped to an ERP material code today, and who owns that mapping by name?
• How many people would need to open a Power BI report — above or below the F64 crossover?
• Which single decision would change if the answer arrived weekly instead of monthly?

Question four decides whether this is worth building. If nothing changes, you are buying an expensive report. If the answer is "we would reallocate trade spend mid-cycle instead of after the quarter", the business case writes itself. We build these estates on Microsoft Fabric, OneLake and Power BI under a Fractional Data Consultant model — first value in six weeks, a working slice of one region's secondary sales, modelled properly.