OTF Forecasting for a Bakery Company

Order-to-fulfil (OTF) planning on Microsoft Fabric for a national bakery brand: a forecasting dashboard on the client's real sales data since October 2026, fed by a contract-first medallion pipeline from an on-premise database.

~21 s to ~1.1 s
Time to first byte after addressing throttling
61.0 s vs 9.5 s
Identical 140-request load on small vs larger capacity
~5 weeks
First commit to production deployment

Role: Sole engineer, responsible for operations
Period: Aug 2026 to Present
Client: National bakery brand
Project type: Featured
Room in the 3D HQ: L3:fabric-forecasting-dashboard

Situation

Planners at a national bakery brand needed a demand-forecasting dashboard, but the sales and master data lived in an on-premise database. The first release reached production on Microsoft Fabric quickly, then loads stalled for about 21 seconds. The next requirement was a pipeline from the client's own source data, and I was the sole engineer, responsible for operations too.

Role and key decisions

Measured capacity throttling before changing the data path
Why: Zero-row and capacity probes showed throttling and corrected my earlier diagnosis, so the fix targeted capacity: an 83,824-row read became about 3,000 streamed aggregates.
Built a contract-first medallion pipeline that stops on failure and resumes
Why: The client's data lived in an on-premise SQL Server, so a data contract, bronze load audits, silver data-quality rules and a reconciled app sync made each stage checkable. Since 8 Oct 2026 the dashboard runs on the client's real data.
Shaped the dashboard around five pages and the planners' own workbook
Why: Planners already work from their workbook, so the OTF table follows its column order, and a drawer explains each forecast and keeps forecaster adjustments.

Results

~21 s to ~1.1 s
Time to first byte after addressing throttling
Measured after removing capacity-heavy indexes and switching to streamed aggregates.
61.0 s vs 9.5 s
Identical 140-request load on small vs larger capacity
Capacity probe isolated the admission delay per request caused by throttling.
~5 weeks
First commit to production deployment
Based on repository and deployment history.
11.7 MB → 156 KB
Data per load of the national summary page on the client's real data, from 39 requests to 5
Measured in pull-request records after moving aggregation into gold summary tables on the F2 capacity, Oct 2026. One row per store and SKU also cut the forecast table's load from 14.1 MB to 2.5 MB on a scale fixture.

Lesson

Planners come to review and adjust a plan, not to look at charts, so the dashboard leads with the plan, and every figure comes from the one Fabric run that owns it. Two baselines is the same as no baseline.