One Foundation, Many Applications: Planning and Pricing on Microsoft Fabric

Most companies think about planning software one application at a time. They buy a demand planning system. Later, they buy a pricing tool. Later still, an analytics platform. Each purchase arrives with its own data integration project, its own connectors to the ERP, its own version of “let’s get your data in.” The company pays for the same plumbing three times.

That is the wrong mental model. The expensive, difficult, repeated part of every one of those projects is the same: assembling clean, current, granular data in one place. The application on top — the forecasting logic, the pricing rules, the dashboards — is the comparatively easy part once the data exists.

Which suggests a better approach: build the data foundation once, then build many applications on top of it.

The foundation and the applications are different layers

We have written separately about why Microsoft Fabric makes an ideal supply chain data foundation — a place where ERP data, factory data, retailer forecasts, and external signal all land, stay current, and stay accessible at the grain planning needs. That article makes the case for the foundation itself.

This one makes the next point: once that foundation exists, it is not dedicated to a single tool. It is a shared base. A demand planning application reads from it. A replenishment engine reads from it. A pricing model reads from it. An executive dashboard reads from it. Each is a different application solving a different problem, but they all draw from the same governed, unified data — instead of each maintaining its own fragile pipeline back to the ERP.

The layers are worth stating plainly:

The foundation (built once)	Microsoft Fabric consolidates ERP data, factory and supplier data, retailer and channel data, and external signal into one governed, current, granular repository.
The applications (built as needed)	Demand planning, replenishment, merchandise financial planning, pricing, financial forecasting, analytics — each built on top of the same foundation, each tailored to the process it serves.

Two applications we have already built on this pattern

This is not theoretical. Two of our planning applications demonstrate the same foundation-plus-application pattern, with different data flowing in for different industries.

Mid-market apparel: SAP + retail + factory data feeding merchandise planning

For a growing apparel brand, the foundation pulls together the sources that define their planning reality: ERP data from SAP (inventory positions, orders, cost), forecast spreadsheets from retail partners (the forward demand signal that arrives by email today), and production and delivery spreadsheets from factories (lead-time reality, ship dates, capacity). None of that lives together in one place in a typical mid-market brand — it is scattered across systems and inboxes. Consolidated in Fabric, it feeds a merchandise planning application that answers what to buy, what to chase, and what to mark down. The demo in that article shows the application; the point here is what sits underneath it.

Growing CPG: NetSuite + SPINS data feeding agile S&OP

For a growing CPG brand, the same pattern draws different inputs. ERP data from NetSuite supplies inventory position and sales history; SPINS data comes in as a periodic data load, adding the retail-channel and category view that NetSuite alone cannot see. Consolidated in Fabric, that combined picture feeds an agile S&OP application that runs a rolling weekly planning rhythm. Different ERP, different external data source, different industry — same architecture. Foundation first, application on top.

Why this matters: the next tool is cheaper than the last

Here is the payoff of building this way. In the traditional model, every new capability is a fresh, expensive integration project — because each application vendor needs its own copy of your data. In the foundation model, the hardest work is already done. The data is unified, governed, and current. Adding a new application means building the logic on top of data that is already there.

That is why the pattern extends naturally beyond planning:

• Pricing. The same foundation that feeds demand planning holds the sales history, inventory, margin, and channel data a pricing capability needs. A pricing tool becomes another application on the foundation, not another integration project. For a firm with deep pricing expertise, this is a natural next build — not a new platform purchase.
• Financial forecasting. Demand and inventory plans already live in the foundation; translating them into revenue and margin forecasts is an application, not an integration.
• Analytics and dashboards. Visibility across the business comes from the same governed data, so every team is looking at one version of the truth.

Each of these used to mean buying another platform and paying to connect it to your systems all over again. Built on a shared Fabric foundation, each is an application layered on data you already have.

Why this is newly possible

Two things changed. Platforms like Microsoft Fabric made it practical to build and maintain a genuine, governed data foundation without an enterprise-scale IT project. And AI-assisted development made building the applications on top — the planning logic, the pricing models, the workflows — dramatically faster than it used to be. Together they invert the old economics: the foundation is achievable, and the applications are buildable, so companies no longer have to buy a separate monolithic platform for every capability they need.

The expensive part was always the data. Solve it once, in one foundation, and everything you build after that gets easier and cheaper — not harder.

Who this is for

This approach fits organizations that need more than one analytical capability and are tired of paying for the same data integration with every purchase — manufacturers and distributors unifying factory, ERP, and shipment data, and growing apparel and consumer brands that have outgrown spreadsheets but cannot justify a million-dollar platform for each problem. If you can see two or three capabilities you will eventually need — planning now, pricing later, analytics throughout — building the foundation first is the decision that makes all of them affordable.

Frequently asked questions

Why build the data foundation before the application?

Because the expensive, difficult, repeated part of every planning software project is the same: assembling clean, current, granular data in one place. The application on top — the forecasting logic, the pricing rules, the dashboards — is the comparatively easy part once the data exists. Buying applications one at a time means paying for the same plumbing over and over, since each vendor needs its own copy of your data.

Can one Microsoft Fabric foundation support more than one application?

Yes. Once the foundation exists it is not dedicated to a single tool — it is a shared base. A demand planning application reads from it, a replenishment engine reads from it, a pricing model reads from it, an executive dashboard reads from it. Each is a different application solving a different problem, but they all draw from the same governed, unified data instead of each maintaining its own fragile pipeline back to the ERP.

What data feeds a mid-market apparel merchandise planning application?

Three sources that rarely live together in a mid-market brand: ERP data from SAP covering inventory positions, orders, and cost; forecast spreadsheets from retail partners carrying the forward demand signal that arrives by email today; and production and delivery spreadsheets from factories covering lead-time reality, ship dates, and capacity. Consolidated in Fabric, that combined picture feeds a merchandise planning application that answers what to buy, what to chase, and what to mark down.

What data feeds an agile S&OP application for a growing CPG brand?

ERP data from NetSuite supplies inventory position and sales history, and SPINS data comes in as a periodic data load, adding the retail-channel and category view that NetSuite alone cannot see. Consolidated in Fabric, that combined picture feeds an agile S&OP application running a rolling weekly planning rhythm. It is a different ERP and a different external data source than the apparel example, on the same architecture.

Does this approach work for pricing as well as planning?

Yes. The same foundation that feeds demand planning already holds the sales history, inventory, margin, and channel data a pricing capability needs, so a pricing tool becomes another application on the foundation rather than another integration project. The same logic applies to financial forecasting, where demand and inventory plans already live in the foundation, and to analytics and dashboards, which draw on the same governed data so every team sees one version of the truth.

How does AI change the build-versus-buy decision?

Two things changed together. Platforms like Microsoft Fabric made it practical to build and maintain a genuine, governed data foundation without an enterprise-scale IT project. And AI-assisted development made building the applications on top — the planning logic, the pricing models, the workflows — dramatically faster than it used to be. Together they invert the old economics: the foundation is achievable and the applications are buildable, so companies no longer have to buy a separate monolithic platform for every capability they need.