Table of Contents
We just got back from FabCon Europe in Barcelona, where planning in Power BI and Fabric was everywhere. And one question kept surfacing across the floor:
“Does it support write-back?”
Increasingly, the answer is yes.
There are established Power BI write-back vendors and newer offerings, and now Microsoft is expanding native planning and data-entry capabilities within Fabric. That gives organizations more options than ever.
But on its own, “yes” tells you very little about what happens once your business starts using it. That is why the questions you ask planning and write-back vendors need to go much further than the input screen.
With Fabric Planning now generally available, Microsoft has brought sheet-based planning and data entry into Fabric as a workload of its own. That’s a welcome development for businesses that already rely on Power BI and Fabric.
But write-back is only the first step.
So, the more important question is: are you adding a place to enter plans, or do you need a complete planning application that works inside the Power BI, Excel and Fabric environment your teams already use, and carries the process behind the input?
The quickest way to tell the two apart is to follow a single number. A regional sales manager raising next quarter’s forecast in a Power BI report makes a good test, because that one saved change sets off far more work than most demos show.
What Happens When a Forecast Changes?
Say demand in the manager’s region is running ahead of plan, so they raise next quarter’s revenue target directly in the Power BI report. Write-back saves the number. That matters. The first basic check is whether the change persists through a view switch and a browser refresh.
But that is only the beginning. The harder question is what that change triggers next.
The change has to spread down to products and months by a rule that Finance agrees with, whether that’s seasonality, last year’s mix, the open pipeline or an even split. Get the rule wrong and a correct-looking total hides unrealistic targets. Every total above the change should move at once, so nobody reviews yesterday’s number. And if part of the forecast is already approved, the system itself has to keep it locked.
Most demos show all of this with one user. A real budget cycle puts 50 contributors in one model in the same week, and nobody’s Tuesday afternoon should get overwritten by someone else’s Wednesday morning. Ask to see two users edit the same planning area, then walk through the change history.
Different jobs call for different Power BI write-back architecture options, and Microsoft’s translytical task flows do handle quick record updates well. For real-world, cross-org planning, though, write-back gets you the first inch into the process. Everything after that takes a comprehensive planning model built for what that input triggers.
Where Write-Back Ends and Planning Begins
A regional forecast adjustment rarely affects Sales alone, so the planning system has to carry the change through to every team that it impacts.
Connect the Input to the Financial Plan
Suppose the manager’s revised forecast raises expected demand by 15%. Operations may need to revisit inventory and production capacity, while Finance needs to see the effect on revenue, costs, margins and cash flow.
A revenue change won’t produce a reliable cash flow forecast unless the relevant drivers and dependencies have been built in. With connected planning across business units, teams can evaluate the change from aligned assumptions instead of reconciling separate departmental plans at month-end.
Keep Versions and Ownership Clear
The manager’s increase might be reasonable, but Finance may want to test it before accepting it. What if demand rises by only 5%? What if supply constraints stop the company from meeting the higher target?
The planning process has to hold those what-if alternatives without confusing them with the approved forecast. The manager also needs a way to explain the adjustment, and the approver needs a clear way to accept or reject it. And very importantly, every change needs a history that makes the decision auditable and traceable.
Make the Plan Part of Your Fabric Data
Once a forecast is approved, it should become data like everything else in Fabric. If the plan lands next to actuals, the same semantic models and data agents that read actuals can read the plan, and plan-versus-actual stops being a monthly export. But if it lands in a side database, you’ve rebuilt a silo that Fabric was bought to remove.
A ‘place to plan’ isn’t the same thing as a ‘planning system’ after all.
5 Questions to Ask in Every Planning Demo
These questions are worth taking into any planning demonstration, whether you’re evaluating an established platform or an approach built within your Microsoft environment. Ask them of every vendor you’re considering, Acterys included. We’re happy to be held to all five.
1. Can Power BI and Excel Work Against the Same Planning Model?
The answer should be yes. Finance isn’t going to abandon Excel simply because another interface supports data entry. A financial analyst might work through detailed assumptions in Excel while regional managers submit their forecasts in Power BI, and both should feed the same governed planning process. Databricks made the same point in September 2026 when it acquired spreadsheet platform Row Zero, calling spreadsheets the most widely used analytics tool in business.
IN A DEMO: Ask the vendor to make a change in Excel and show it in the Power BI planning view, then reverse the process. While you’re there, check whether write-back behaves the same way in every view and mode. If either direction relies on an export, the plan is already splitting in two.
2. Can Business Users Maintain the Planning Process?
The person responsible for the forecast isn’t necessarily the person who understands DAX or Fabric workspace administration. If Finance introduces a new cost center or changes an allocation rule, someone has to decide whether it needs an IT ticket. The process slows, and another request lands in the Data or IT team’s queue.
Self-service works best when Data & IT can keep ownership of the data and the architecture while planning owners, the people responsible for the plan or forecast, can control the process they’re accountable for. Ask the question. Anything other than “the end user (with proper permissions) can manage their own plan” means Finance and the business is dependent on the speed of the IT or Data teams’ ticket queue.
IN A DEMO: Ask them to change an existing model, not just enter data into a prepared one. Check the documentation too, because if it’s too thin to predict how the product behaves, your team will find that the edge cases live, in production.
3. Who Can See and Change Sensitive Planning Data?
For workforce planning, a regional controller might need to edit departmental headcount without seeing compensation data outside their responsibility. Only controlling which Power BI report someone can ‘open’ isn’t enough. Security needs to carry through to the underlying data and the write-back process.
IN A DEMO: Ask whether row-level security is enforced at the data connection and during write-back, or only in the reporting layer. Test it with two users who have different access rights. Confirm where row-level security is enforced across the reporting layer, data connection and write-back path.
4. Who Decides What a User Can Do: You or Their Last Click?
Some planning tools assign roles dynamically based on what a user does inside the application, rather than having every role explicitly assigned in advance by an administrator. That means an action taken by the user can change the planning role they are operating under, potentially affecting both what they can do and what their usage costs.
IN A DEMO: Ask what actions can change a user’s role, how long that role lasts, and whether administrators can control and see those changes. Then ask what that means for cost.
A user’s last click shouldn’t create a surprise about the role they’re operating under or what you’re being billed for.
5. What Will It Cost Me?
Ask for the actual per-user, per-month number for how your team would use the product. A pricing page tells you what each edition includes. A quote built on your contributor count and deployment, including any Fabric capacity the workload consumes, tells you what you’ll actually pay in year one and year two.
If the honest answer is that it depends on consumption in ways nobody can fully predict, that’s worth knowing before month two rather than halfway through it. Ask which parts of the cost are fixed and who controls the parts that move.
IN A DEMO: Ask for the actual per-user, per-month cost for your team and use case, including any Fabric capacity assumptions. Ask what’s fixed and what can change.
How Acterys Answers the Same Five Questions
Every answer below draws on capabilities documented on acterys.com, so you can check each one.
When a Forecast Changes
With Acterys: Top-down changes spread through allocation methods such as prior-year patterns, and bottom-up entries roll up through the same model. Controllers can lock submitted plans while version control keeps scenarios separate. In Fabric deployments, row-level security on the write path limits each manager to their own rows, and every ‘write’ records who made it and the value it replaced, so neither conflicting edit disappears.
1. Can Power BI and Excel Work Against the Same Planning Model?
Acterys Answer: Excel and Power BI Share One Model
Finance works in Excel through the Acterys add-in, which saves values to the same central database the Acterys Power BI visuals use, so a change on either surface appears on the other without an export.
2. Can Business Users Maintain the Planning Process?
Acterys Answer: Planning Owners Maintain the Model
Planning owners maintain hierarchies and allocation rules in the low-code Acterys Modeller, while the Premium edition’s Dev/Test/Prod separation lets IT control how those changes reach production.
3. Who Can See and Change Sensitive Planning Data?
Acterys Answer: Security Follows the Signed-In User
Writes run in the signed-in user’s Entra ID context instead of through a shared service account, so the security defined at the data layer governs each write. Our guide to secure write-back in Microsoft Fabric covers the detail.
4. Who Decides What a User Can Do: You or Their Last Click?
Acterys Answer: Administrators Grant Access
Administrators assign user-level permissions for what each person can view and modify, all inside the Entra ID governance you already run.
5. What Will It Cost Me?
Acterys Answer: You get a Real Number Before You Start
We can give you a per-user, per-month number before you start, and we’d expect you to hold us to it. Every package includes the write-back engine, the Modeller, hosted data management with a storage allowance and unlimited viewer licenses, so the cost is set by your licenses and the Acterys edition you choose. If you run Acterys in your own Fabric capacity, size that workload with your data team and add it to the estimate, since we can’t quote Microsoft’s side.
And don’t forget; when bought through Azure Marketplace, Acterys counts toward your Microsoft Azure Consumption Commitment (MACC), so it can draw on Azure spend you’ve already committed.
Put Acterys to the Same Test
If you’re evaluating Power BI write-back or planning options, bring us your use case and ask us the same five questions.
Show us where your users work today, what they need to change or contribute, and what needs to happen after that input. We’ll walk through how Acterys approaches the planning model, governance and process behind the write-back, and how it would work in your Power BI and Fabric environment.
We’re happy to be held to the same standard, and we’d love to have the conversation.
Want to go deeper on Microsoft Fabric Planning specifically? Read our deeper look at Acterys and Fabric Planning, including where the approaches differ as planning expands across users, processes and the enterprise.
Talk to us about your planning and write-back in Power BI requirements
