Beyond Planning Sheets: Extending Business Planning with PowerTable in Microsoft Fabric

Beyond Planning Sheets: Extending Business Planning with PowerTable in Microsoft Fabric

In our previous article, we explored how Planning Sheets in Microsoft Fabric can bring forecasting and scenario planning closer to the data organisations already manage in Fabric.

But building the plan is only part of the process.

Behind almost every plan, report or business model are smaller datasets that need to be maintained over time: product mappings, cost centre classifications, workforce requirements, allocation rules, planning assumptions and many others.

These datasets are often maintained by the people who understand the business best. A product manager knows which product belongs to which range. Finance knows how accounts should be grouped. A department manager knows what additional resources will be required next quarter.

The challenge is that those people may not know SQL, Python or how the underlying data platform has been built.

And they shouldn't necessarily need to.

This is where PowerTable becomes interesting.

What Is PowerTable?

PowerTable is a no-code table application capability within Microsoft Fabric Plan.

On the surface, the experience is deliberately familiar: rows, columns and structured fields that business users can work with much like they would in a spreadsheet.

Underneath, however, the data can be stored in a Fabric SQL database and connected to the wider Fabric environment.

That distinction is important.

The value of PowerTable isn't simply that it gives users another table to edit. It creates a way for business users to maintain structured data without having to work directly with the technical layer underneath it.

The data team can establish the database, model, relationships and appropriate controls. Business users can then work with the information they actually understand.

This creates an interesting middle ground between two familiar approaches:

Excel is easy for business users to maintain.

Databases are structured and easier to integrate into enterprise data solutions.

PowerTable brings elements of those two worlds together: a familiar business-user experience backed by structured data in Fabric.

A Common Business Problem: Who Maintains the Mapping?

Consider something that exists in almost every organisation: mapping data.

An organisation may receive product transactions from its operational systems using product codes or SKUs. Those codes work perfectly well for processing transactions, but they don't necessarily contain all the business context needed for planning and reporting.

The business may need something like this:

The important question isn't whether this table is complicated.

It isn't.

The interesting question is:

Who should maintain it?

The commercial or product team may know that Product B should now be treated as part of the Core Range rather than the Seasonal Range.

But traditionally, that simple business decision can create a surprisingly technical process.

The change might be sent to the data team. Someone updates a spreadsheet, database table or transformation. The mapping is then incorporated into the data model before it eventually reaches reporting or planning.

The person who knew the correct answer from the beginning couldn't necessarily make the change themselves.

Bringing the Business User into the Process

PowerTable provides another way to approach this.

Instead of asking the product owner to understand database tables, IDs or SQL, they can work through a table application designed around the business information they already understand.

They might simply see:

Product B → Planning Group → Core Range

The technical solution underneath can still use IDs, relationships and proper data modelling. That doesn't have to become the business user's problem.

For example, the underlying structure could maintain both the business-friendly description and the identifier required by the data model:

The business user maintains the business meaning.

The data platform handles how that information is connected and used downstream.

This pattern isn't limited to products.

The same idea can apply to:

• account-to-reporting-group mappings;

• cost centre classifications;

• customer segments;

• sales territories;

• department mappings;

• vendor classifications; and

• allocation categories.

These are small datasets, but they can influence how an organisation plans, reports and analyses its business.

When a Spreadsheet Becomes a Business Process

Of course, many organisations already manage this kind of information in Excel.

And Excel isn't automatically the problem.

For a small list maintained by one person, a spreadsheet may be perfectly adequate.

The challenge appears when that spreadsheet becomes part of a shared business process.

Which version is current?

Who changed the classification?

Was the change reviewed?

Has the latest version reached the reporting model?

Can everyone who needs the information access the same version?

At that point, maintaining the spreadsheet can become more difficult than maintaining the actual data.

PowerTable provides a familiar table-based experience while allowing that business-maintained data to sit within a more controlled Fabric environment.

This is where the no-code aspect matters.

The objective isn't to turn a Finance Manager, Product Manager or Operations Manager into a data engineer.

It's to let them maintain the information they are responsible for without requiring them to become one.

It Doesn't Have to Be Master Data

Product mappings are a useful example because almost any organization can relate to them. But the same PowerTable pattern can also be used for information that changes as the business changes.

Consider workforce planning.

A department manager may know that additional resources will be needed next quarter. They might need to maintain something as simple as:

Again, the manager understands the information.

They know which role is required, when it is required and how many people they expect to need.

They shouldn't need Python to communicate that requirement to the planning process.

PowerTable can provide a structured place for those inputs to be maintained, while the organisation decides how they are reviewed and how they eventually contribute to the wider plan.

Different Businesses, Different Inputs

The specific data that matters will naturally vary between organisations.

A multinational organisation might maintain exchange-rate assumptions used for budget and forecast scenarios.

A retailer or manufacturer might maintain seasonality factors that influence expected demand across different periods.

Finance might maintain allocation percentages.

Sales Operations might maintain territory assignments.

FP&A might maintain planning scenarios or planning windows.

The scenarios are different, but the underlying requirement is the same:

Business users understand the values. They need a controlled way to maintain them without having to work directly with the technical data layer.

This is the broader PowerTable use case.

Governance Still Matters

Giving business users greater control doesn't mean giving everyone unrestricted access to everything.

In fact, once business-maintained data starts influencing reporting and planning, governance becomes more important.

A product owner may be allowed to propose a change to a product classification. Finance may need to approve certain mappings. Other users may only need read access.

PowerTable can support this type of controlled process through permissions, approval workflows and change history.

Instead of a process such as:

Edit spreadsheet → Email spreadsheet → Confirm latest version

the process can move toward:

Edit → Review → Approve → Use

For some data, history may also matter.

If a product moves from one reporting group to another today, should last year's reporting also change? Or should historical reporting preserve the classification that applied at the time?

PowerTable can support Slowly Changing Dimension patterns for scenarios where that historical context needs to be retained.

Where Does Planning Fit?

This brings us back to Planning Sheets.

PowerTable and Planning Sheets solve different parts of the business process.

Planning Sheets help users build and adjust the plan.

PowerTable helps business users maintain some of the structured data, mappings, rules and assumptions that the plan may depend on.

They don't have to contain the same information.

For example, an existing planning model may already contain planned sales by product. PowerTable doesn't need to recreate that plan.

Instead, it might maintain the product mapping that determines which planning group each SKU belongs to.

Similarly, a planning model might already contain revenue forecasts. PowerTable could maintain an exchange-rate assumption that is used when those forecasts are converted into another currency.

The existing plan remains the plan.

PowerTable maintains supporting business data that can influence how that plan is interpreted, grouped or calculated.

[

Caption: Business-maintained data can become part of the same Fabric environment used for planning and analytics.

From Business Knowledge to Connected Data

This is ultimately what makes PowerTable interesting.

Organisations already have people maintaining important business information.

The product manager knows the correct product classification.

The Finance team knows the allocation rule.

The department manager knows the workforce requirement.

The planning team knows which assumptions should apply to the next forecast.

The question is whether those people need to pass every change through spreadsheets and technical teams before the information can become part of the wider data environment.

PowerTable provides another option.

Business users can maintain the structured information they understand through a familiar interface, while the data team remains responsible for the architecture underneath: how the data is stored, related, governed and ultimately used.

That separation is important.

The business owns the business meaning.
The data platform manages how that meaning is connected.

The Bottom Line

PowerTable isn't interesting simply because it lets someone edit rows in Microsoft Fabric.

Its real value is who can maintain those rows.

A product manager shouldn't need SQL to change a product classification.

A department manager shouldn't need Python to update a workforce requirement.

And a Finance user shouldn't need to understand the underlying database architecture simply to maintain a business assumption.

PowerTable gives those users a familiar way to maintain structured business data while keeping that information connected to the wider Fabric environment.

For organisations already exploring Microsoft Fabric Plan, that creates a useful distinction:

Planning Sheets help business users build the plan.
PowerTable helps them maintain some of the business data behind it.

And PowerTable's usefulness doesn't stop at planning.

Wherever important business knowledge is currently sitting in a spreadsheet waiting for someone technical to turn it into structured data, there may be a PowerTable use case.

If Planning Sheets help answer “What do we expect to happen?”, PowerTable helps manage some of the structured data behind “How did we build that plan?”