Expert Perspective: Dimension Design Should Start With Reporting Decisions, Not With a List of Departments

In Business Central, dimensions are most valuable when they answer a business question such as “Where are we spending?” “Which department is performing?” “Which project is profitable?” or “Which business unit generated this revenue?” They allow transactions to be analysed without creating a separate G/L account for every reporting combination. Microsoft describes dimensions as a way to group posted entries for reporting and analysis across journals, documents, budgets, and ledger entries. Microsoft Learn

The important architectural principle is:

Design dimensions around how management needs to analyse the business, not around every piece of information the organisation happens to have.

Start With the Reporting Questions

Before creating a dimension called DEPARTMENT, LOCATION, PROJECT, or BUSINESS UNIT, ask:

• What management decision will this dimension support?
• Who will use the information?
• At what transaction level must it be captured?
• Does the value change frequently?
• Is the information already represented elsewhere in Business Central?
• Will users consistently enter the dimension?
• Does the organisation actually need reporting at this level of granularity?

For example, if management wants:

“Show operating expenses by department.”

Then DEPARTMENT is a logical dimension.

But creating separate dimensions for:

Department + Employee + Manager + Floor + Building + Team + Desk

simply because the information exists can create unnecessary complexity.

A Practical Dimension Model for a Growing Organisation

A typical starting model might look like:

But this should not become a mandatory template for every Business Central implementation.

The right dimensions depend on the organisation's reporting requirements.

Don't Turn the Chart of Accounts Into a Reporting Database

This is one of the strongest reasons to use dimensions properly.

Imagine an organisation creates G/L accounts like:

610000 - IT Expense
610001 - IT Expense - India
610002 - IT Expense - UK
610003 - IT Expense - US
610004 - IT Expense - India - Project A
610005 - IT Expense - India - Project B

This can quickly become difficult to maintain.

Instead, the organisation might use:

G/L Account: IT Expense

Department: IT
Location: India
Project: Project A

Now the same G/L account can be analysed through multiple reporting perspectives.

The key principle is:

G/L accounts should primarily represent the nature of the financial transaction; dimensions should provide additional analytical context.

Choose Global Dimensions Carefully

Business Central allows two global dimensions, which can be used as filters in reports, batch jobs, XMLports and other areas. It also supports up to eight shortcut dimensions for convenient entry on journals and documents. Microsoft Learn

Therefore, don't choose global dimensions simply because they are the first two dimensions the implementation team creates.

Choose dimensions that are:

• Frequently used
• Broadly applicable
• Important for management reporting
• Frequently filtered
• Stable over time

For example, an organisation might choose:

DEPARTMENT

and

LOCATION

as global dimensions because management frequently analyses transactions by those dimensions.

Another organisation may have a completely different requirement.

Default Dimensions Are a Major Part of Good Design

One of the most practical Business Central features is Default Dimensions.

For example:

Customer: ABC Ltd
Default Dimension:
Department = SALES

When the customer is used in a transaction, Business Central can suggest the relevant dimension.

Similarly, dimensions can be associated with customers, vendors, items, locations and other master data. Microsoft Learn

This reduces manual entry and improves consistency.

But there is an important principle:

Default does not necessarily mean mandatory.

A default value should represent what is normally expected. A mandatory dimension should represent information that the business cannot allow to be missing.

Mandatory Dimensions Need Business Justification

Suppose every IT expense must have a department.

You might configure:

Account: IT Expense
Dimension: DEPARTMENT
Value Posting: Code Mandatory

Now the user cannot post the transaction without providing the required dimension.

Business Central supports posting rules such as mandatory and same-code requirements for default dimensions. Microsoft Learn

But be careful.

If you make too many dimensions mandatory, users may start selecting arbitrary values simply to get the transaction posted.

That creates technically complete but analytically unreliable data.

Control Conflicting Default Dimensions

This becomes particularly interesting in real implementations.

Suppose:

Customer → Department = SALES

but:

Item → Department = PRODUCTION

and:

Location → Department = WAREHOUSE

Which one should win?

Business Central provides Default Dimension Priorities to manage situations where dimensions come from multiple sources and conflict. Microsoft Learn

This is an important configuration area that beginners often overlook.

The implementation team should explicitly document:

Which source has priority when multiple master records provide conflicting dimension values?

Do not leave this behaviour to user assumptions.

Dimension Combinations Add Another Governance Layer

Dimensions should not only be individually valid.

Sometimes certain combinations should be prohibited.

For example:

Department = R&D
Location = Retail Store

may not make business sense.

Business Central allows dimension combinations to be configured as:

No limitation

Limited

Blocked

so that inappropriate combinations can be prevented or restricted. Microsoft Learn

This is particularly useful when the number of departments, locations, projects and business units starts increasing.

Think About Dimension Governance

Imagine a company starts with:

DEPARTMENT
FIN
HR
IT
SALES

Two years later:

FIN
FINANCE
FIN-01
FINANCE-IND
FIN-IN

Now reporting becomes unreliable because users have created multiple values representing essentially the same business concept.

Therefore, dimension governance should define:

• Naming conventions
• Value codes
• Who creates dimension values
• Who can block values
• When old values should be blocked
• Whether values can be reused
• How new organisational structures are introduced
• How reporting hierarchies are maintained

Business Central supports hierarchical dimension values, allowing values to be structured for aggregation and reporting. Microsoft Learn

Don't Create a Dimension for Something Business Central Already Models

This is another important design principle.

Before creating a custom dimension, ask:

“Does Business Central already have a proper master-data or transactional concept for this?”

For example, if something is already represented by:

• Customer
• Vendor
• Item
• Location
• Employee
• Project
• G/L Account

you should carefully consider whether duplicating it as a dimension creates unnecessary data maintenance.

Dimensions should add analytical context, not duplicate the entire application data model.

Consider Reporting Combinations Before Implementation

Suppose management wants to analyse:

Profit
   ↓
Business Unit
   ↓
Department
   ↓
Location
   ↓
Project

Then the design needs to ensure that the relevant dimensions are captured consistently across transactions.

For example:

Revenue
Business Unit = Consulting
Department = Delivery
Location = India
Project = P1001

and:

Expense
Business Unit = Consulting
Department = Delivery
Location = India
Project = P1001

Now reporting can compare revenue and cost within the same analytical context.

The objective is not simply to have dimensions.

The objective is to have consistent dimensional data across the transactions being compared.

Understand Dimension Sets

There is also an important technical concept behind Business Central dimensions.

When a transaction contains a combination of dimension values, Business Central stores that combination using a dimension set ID rather than repeatedly storing every dimension value directly on the transaction. A dimension set represents a unique combination of dimension values. Microsoft Learn

For developers and technical consultants, understanding this becomes useful when working with:

• AL development
• APIs
• integrations
• posted entries
• performance
• dimension-related customisations

This is where functional understanding and technical understanding start connecting.

A Strong Enterprise Design Process

For an implementation project, I would approach dimension design like this:

Business Reporting Requirements
          ↓
Management Questions
          ↓
Required Analytical Perspectives
          ↓
Dimension Definition
          ↓
Dimension Values
          ↓
Global / Shortcut Dimensions
          ↓
Default Dimensions
          ↓
Default Dimension Priorities
          ↓
Dimension Combinations
          ↓
Posting Validation
          ↓
Financial Reporting

The important part is that configuration comes after requirements analysis.

A Real-World Example

Consider a growing professional-services company.

Management wants to answer:

How profitable is each business unit?

Which department is generating the highest cost?

Which location is performing best?

Which projects are profitable?

A possible model could be:

G/L Account
      +
Business Unit
      +
Department
      +
Location
      +
Project

Example:

G/L Account    = Consulting Revenue
Business Unit  = Consulting
Department     = Delivery
Location       = India
Project        = CRM-2026-001

Now the organisation can analyse the same financial data from several perspectives without creating separate G/L accounts for every combination.

That is where dimensions become extremely powerful.

What Students and Freshers Should Practise

Create a small Business Central company and build a scenario with:

3 departments

2 locations

3 projects

Then configure:

1. Dimensions
2. Dimension values
3. Global dimensions
4. Shortcut dimensions
5. Default dimensions
6. Mandatory dimensions
7. Default dimension priorities
8. Dimension combinations

Then post:

• Sales transactions
• Purchase transactions
• General journals
• Project-related transactions

Finally ask:

Can management produce the reports they originally requested without manually manipulating the data outside Business Central?

That is the real test of your dimension design.

Interview-Level Question

A strong Business Central interview question would be:

“The finance team wants reporting by department, location and project. Would you create separate G/L accounts for every combination?”

A strong answer should be:

“No. I would first determine which information represents the nature of the financial transaction and which represents analytical context. I would normally keep the chart of accounts manageable and use dimensions for additional reporting perspectives, then configure default dimensions, mandatory rules, priorities and dimension combinations to maintain data quality.”

That demonstrates much stronger understanding than simply saying:

“Dimensions are used for reporting.”

Points to remember

A well-designed dimension model should achieve three things:

Meaningful reporting

Management can analyse the business from the perspectives that actually matter.

Consistent data

Users are guided toward correct dimension values instead of manually entering everything.

Controlled complexity

The organisation gets useful analytical flexibility without creating hundreds of unnecessary G/L accounts or dimension values.

The best question to ask before creating any dimension is:

“What business decision or reporting question will this dimension help us answer?”

If there is no clear answer, the dimension probably needs to be reconsidered.

For students and freshers, learning the configuration is important. For working professionals and Business Central consultants, the bigger skill is learning to translate business reporting requirements into a sustainable dimension architecture.

That is what makes dimension design an implementation and architecture decision rather than simply a configuration exercise.