Canlak Coatings Swaps Planusethisfinal.xlsx for Fabric Planning
According to Microsoft, Canlak had run its daily reporting on Microsoft Fabric for close to two years. That setup included a governed Power BI semantic model used across the company and an enterprise data warehouse on OneLake, with a governed "gold" layer in a medallion architecture. In that layered data-lake pattern, the gold tier holds the curated, business-ready tables.
Sales forecasting sat entirely outside that platform. The forecast lived in a spreadsheet and worked at sales-rep and customer level. Actuals in Fabric updated daily at product level. Taking the forecast down to product level meant more tabs, more links and more manual reconciliation against those actuals, and the forecast was refreshed far less often than the data it was meant to track.
Microsoft's story illustrates the version-control problem with filenames most finance teams will recognise: Planv1.xlsx, Planv2.xlsx, Planv3final.xlsx and Planusethisfinal.xlsx. Drafts went out by email and came back from several reviewers. There was no audit trail, no version control and no reliable single source of truth. Finance staff spent their time tracking files and reconciling numbers when they should have been analysing them.
Canlak says it wanted to extend the governed reporting platform into planning, not add a separate forecasting system. It chose the planning capability in Fabric IQ because planning sheets run on an existing Power BI semantic model, with no separate planning database or modelling engine to maintain. Microsoft's story says there was no formal competitive evaluation. This case shows a company extending a platform it already used. It is not a head-to-head comparison with dedicated planning products.
One Power BI Semantic Model Feeds Both Reports and the Planning Sheet
Canlak worked with implementation partner Data Crafters to put Fabric Planning on top of its existing OneLake warehouse. Data moves through Fabric pipelines into OneLake and then into the governed Power BI semantic model. That one model feeds both the Power BI reports and the Fabric Planning sheet.
Security is the part admins should look at first. Microsoft says the planning sheet inherits the row-level security (RLS) of the imported semantic model, so the access rules that already applied to reporting also apply to forecasting. Canlak did not have to rebuild them. The story gives no RLS roles, predicates or test procedure, so it shows that the approach worked for Canlak but not how its security was set up.
Microsoft's product documentation confirms the basic design. Actuals stay read-only in the semantic model. A separate Fabric SQL database stores all plan data: inputs, forecasts, scenarios and writeback entries. According to the Fabric Planning FAQ, the separation exists so plan data can be written back without affecting the underlying actuals or the reporting layer. The Get Started guide adds that when you create a plan item, you also automatically create a Fabric SQL database in your workspace. This database stores your plan report's metadata.
The practical result is that a planner cannot overwrite historical revenue by typing into a forecast cell. Forecasts live in their own governed store, and reports can set them beside actuals through the shared model. Microsoft sums up its broader pitch by saying planning is built on Fabric semantic models, ensuring that planning and analytics share the same trusted business logic.
A Segment-to-Product Hierarchy Built in Under Four Weeks
Rich Zielinski, Canlak's director of finance and treasury, led the design of a planning hierarchy with four levels: segment, sales representative, customer and product. Users can enter values at any level and distribute them up or down the hierarchy. For example, a figure entered at segment level can be spread across the customers and products beneath it.
The model's rules are straightforward:
- Revenue is calculated as volume multiplied by the latest price.
- Actuals stay read-only.
- Plan data writes back to a SQL database inside Fabric.
- The model covers five segments, two currencies and more than 40 sales representatives, and it runs in the Canada Central Azure region.
Microsoft says the project went from kickoff to a working forecast in under four weeks. Data Crafters designed the hierarchy, configured the Plan engine logic and extended the semantic model's security into the planning layer.
That timeline depends on Canlak's starting point. Microsoft's own summary credits the company's existing data foundation, single semantic model, inherited security and single source of truth for making it possible. A company still assembling its warehouse or reconciling several competing Power BI models would be starting from a different place.
The Fabric Planning FAQ lists a modelling constraint that explains why a clean semantic model matters. You can combine dimensions from different tables on one planning sheet only if those tables are related in the semantic model. Unrelated tables will not cross-filter correctly. A segment-rep-customer-product hierarchy like Canlak's needs those relationships to be modelled properly first.
What the 75–80% Forecast-Cycle Reduction Claim Rests On
Microsoft reports that Canlak's forecast cycle fell from three to four weeks to about one week. It describes that as a 75 to 80 percent reduction in the time finance spends producing each cycle. The forecast also moved from customer level to product level with no manual reconciliation, because plans and actuals share one semantic model. Canlak now has a rolling 12-month view that is refreshed monthly, and finance users enter forecast figures in the planning sheet each month while keeping full-year visibility.
Zielinski's quote in Microsoft's story says work that used to take "three to four weeks of spreadsheets, emails, meetings and reconciliations" can now be done in about a week. Microsoft also used the same quote in its general-availability announcement for Fabric Planning. It appears there among feedback from customers and partners who used Fabric Planning through the public preview phase.
These results come from a vendor case study with the customer's endorsement. Microsoft gives no method for the timing figures, no cost numbers and no capacity metrics. The story does describe a clear mechanism for the time saved. The reconciliation work that once filled the gap between a customer-level forecast and product-level actuals disappears when both sit on the same model.
Fabric Planning Billing Changes the "No Extra Cost" Math
Canlak reports no increase in platform cost and no noticeable increase in capacity use. Read that claim alongside Fabric Planning's release history. Microsoft introduced Planning in Fabric IQ at FabCon Atlanta in March 2026 and said the capability was co-engineered with Lumel, an award-winning innovator in enterprise performance management. During the preview, Microsoft's billing post said customers would see usage only - no charges and no dollar amount; billing begins with General Availability. Microsoft later confirmed that Planning in MS Fabric billing will start on August 1st, 2026. The independent Fabric Planning newsletter puts the general-availability date at July 28, 2026.
Here is an inference: Canlak's quote was used as preview-phase feedback, so at least part of its "no extra cost" experience probably came before metering started. Microsoft's story does not say which billing period its cost statement covers. That timing matters for anyone budgeting a similar project.
The billing model uses Fabric capacity instead of per-seat licences. Microsoft says everything within Planning consumes your existing Fabric CUs, with no separate subscription or licensing requirements. Charges depend on the user's role: Viewers have read-only access, Stakeholders are active contributors, and Planners design models and run scenarios. Microsoft's later update describes an activity-based, session-driven model that bills only against your Fabric capacity. Planning usage also shows up in the Microsoft Fabric Capacity Metrics app, where admins can filter to Experience = Planning to see Planner/Viewer sessions (and automation jobs) and the CUs each consumes.
For per-role rates, the Fabric Planning newsletter reports that the rates came through GA unchanged: 1.16 CU for a Planner, 0.23 for a Stakeholder, 0.05 for a Viewer, the 30-day session. The same newsletter notes that Microsoft's billing document was still labelled Preview when it wrote, and it advises readers to confirm current terms with Microsoft. A companion third-party FAQ explains the sizing effect: one Planner holds 1.16 CU, which is 58% of an F2's total 2 CU. That is why one Planner alone nearly fills the smallest SKU, and why F4 is the realistic floor for production planning.
Canlak's story does not say how its 40-plus sales representatives and finance users are split across those roles. That split largely determines the capacity bill, so Canlak's cost outcome cannot be carried over to another organisation. A team with mostly Viewers and a few Planners will size its capacity very differently from one where every rep holds a Planner session.
What This Means for Fabric and Power BI Admins
If your company already has a governed Power BI semantic model on Fabric and still runs forecasting in emailed spreadsheets, Canlak's setup is worth piloting. Price it with the billing that took effect on August 1, 2026, not the preview-era experience. Organisations whose semantic models are still split up or poorly related should fix that first, because the planning layer depends on it.
The Fabric Planning FAQ lists these prerequisites and constraints:
- Creating a plan item requires Contributor or higher access to the Fabric workspace and at least Build access to the semantic model.
- Each plan item connects to one semantic model, and that connection cannot be changed after it is made. Planning against different data sources needs separate plan items, so choose the model carefully before you build.
- The semantic model can live in a different workspace. Users still need at least Viewer access to that workspace for the model to appear in the connection dialog.
- Contributors cannot create a semantic model connection themselves. A workspace admin has to create it, and then they can use it.
- Writeback works only to a Fabric SQL database, and that database must exist before you try writeback.
Microsoft's overview adds that setup involves tenant settings, capacity settings, semantic model connection-owner permissions and database connections, so the Fabric admin needs to be involved from the start.
Key takeaways:
- Canlak's reported drop from three or four weeks to about one week per forecast cycle comes mainly from removing reconciliation between a customer-level spreadsheet forecast and product-level actuals.
- Fabric Planning keeps actuals read-only in the semantic model and writes forecasts to a separate Fabric SQL database, so plan entries cannot change reporting data.
- Canlak reports that its planning sheet inherited the imported semantic model's row-level security, but it published no role design or testing details, so test your own RLS before rollout.
- Canlak's "no increase in platform cost" claim should not be applied to other companies, because Planning is now billed by role-based 30-day sessions against Fabric capacity.
- Use the Capacity Metrics app with the Planning experience filter to measure real consumption during a pilot before choosing an F-SKU.
- Because a plan item's semantic model connection cannot be changed, settle which model the plan will use before anyone builds a sheet.
Canlak's case shows what Fabric Planning offers a company that has already done the data-foundation work: the forecast moves onto the same model, security and pipelines that already run reporting, and the reconciliation gap closes. Canlak says it is considering extending the same approach from sales into wider financial planning on the same governed model. Other organisations weighing a similar move now have paid billing to plan around, so a capacity estimate needs to be part of the project from day one.