4.3 Default Dimensions, Combinations & Priorities

4.3 Default Dimensions, Combinations & Priorities

Exam Focus: A major portion of the MB-800 certification evaluates your ability to implement dimension governance. You must master default dimensions on master records and account types, know the exact behavior of every Value Posting option (Code Mandatory vs. Same Code vs. No Code vs. Allowed Values), configure Dimension Combinations and Dimension Value Combinations, and resolve default dimension priority clashes when transactions draw conflicting defaults from customers, items, and accounts.

Without rigorous governance rules, automated defaulting, and validation constraints, user data entry in an ERP system quickly results in missing, contradictory, or invalid dimension assignments. Dynamics 365 Business Central provides a comprehensive governance triad: Default Dimensions, Dimension Combinations, and Default Dimension Priorities.

---

1. Default Dimensions on Master Data & Account Types

To automate data entry and prevent omissions, consultants configure Default Dimensions. When a master record (such as a customer, vendor, or item) is selected on a document or journal line, Business Central automatically transfers its default dimensions onto the transaction.

Entities Supporting Default Dimensions

• Master Data Entities: Customer Card, Vendor Card, Item Card, Resource Card, Fixed Asset Card, Project (Job) Card, Location Card.
• Financial Account Types: G/L Account Card, Bank Account Card.

Single vs. Multiple Default Dimension Assignment

Business Central provides two methods to configure default dimensions:

1. Dimensions-Single (Page 540): Configures default dimensions for a single selected record.
   • Navigation: Open entity card (e.g., Customer Card) -> Related > Customer > Dimensions.
2. Dimensions-Multiple (Page 542): Configures default dimensions across multiple selected records simultaneously.
   • Navigation: Open entity list (e.g., Customers list) -> highlight multiple rows -> Related > Customer > Dimensions-Multiple.
   • Any rule configured in this modal window is applied across all selected records in a single batch, dramatically accelerating initial ERP configuration.

Default Dimension Record Fields:
  ├── Dimension Code: [DEPARTMENT]
  ├── Dimension Value Code: [SALES] (Required for Same Code; Optional for Code Mandatory)
  ├── Value Posting: [Code Mandatory | Same Code | No Code | Blank]
  └── Allowed Values Filter: [SALES|MKTG] (Restricts selectable values)

---

2. Value Posting Rules: Mechanics & Transactional Validation

The Value Posting field on a Default Dimension record controls how strictly the posting engine validates that dimension during journal entry and document posting. Business Central offers four distinct Value Posting options:

1. Blank / Optional (Default)

• Setup: A Dimension Value Code may be populated as a suggestion or left blank.
• Behavior: The default value automatically populates on document and journal lines. However, the user is free to overwrite the value, select a different value, or delete it entirely.
• Posting Validation: The system performs no validation at posting. The line posts successfully whether the dimension is populated or empty.

2. Code Mandatory

• Setup: Dimension Value Code can be pre-populated (as a suggested default) or left blank.
• Behavior: When posting a document or journal line, Business Central validates that some valid dimension value is present for this dimension code.
• Posting Validation: If the dimension value is blank, posting halts immediately with an error: "Select a Dimension Value Code for the Dimension Code [DEPT] for [G/L Account 61100]." If any active dimension value for that dimension is populated, posting succeeds.
• Ideal Scenario: Operational expense accounts (e.g., 61100 Travel Expenses or 62000 Office Supplies) where an organization mandates that every expense must be charged to a department, but the specific department depends on the individual submitting the expense.

3. Same Code

• Setup: Dimension Value Code must be populated in setup.
• Behavior: Enforces that the transaction line must carry that exact, specific dimension value code.
• Posting Validation: If a user changes the value to another code or leaves it blank, posting fails with: "The Dimension Value Code [SALES] is not allowed for Dimension Code [DEPT] for [G/L Account 61100]. The Dimension Value Code must be [MKTG]."
• Ideal Scenario: Dedicated accounts linked to specific functional entities, such as a localized revenue account (40110 Domestic Sales - North) locked strictly to AREA = NORTH.

4. No Code

• Setup: Dimension Value Code must remain blank in setup.
• Behavior: Enforces that the transaction line must not contain any dimension value for this dimension code.
• Posting Validation: If a dimension value is populated, posting is blocked: "Dimension Value Code must not be specified for Dimension Code [DEPT] for [G/L Account 10100]."
• Ideal Scenario: Balance sheet cash or bank accounts (10100 Operating Checking) where departmental tagging would corrupt cash-flow and balance-sheet reporting.

Value Posting Rule Comparison Matrix

The Allowed Dimension Values Feature

To provide flexible yet controlled entry, Business Central allows administrators to define an Allowed Dimension Values Filter on Default Dimension lines (Page 543):

• Scenario: Customer A operates in the eastern territory and should only be assigned sales representatives from REP-01, REP-02, or REP-03.
• Setup: Under Default Dimensions, select the SALESREP dimension and click Allowed Dimension Values. Check only the three permitted representatives.
• Result: In the Sales Order lookup, the user can only see and select those three approved values. If they attempt to enter REP-04, Business Central rejects the input.

---

3. Dimension Combinations & Dimension Value Combinations

While Default Dimensions govern individual accounts and entities, Dimension Combinations govern relationships between different dimensions to prevent illogical business pairings.

The Dimension Combinations Matrix (Page 538)

UI Navigation Path:
Tell Me (Alt+Q) -> Dimension Combinations

The Dimension Combinations page displays a two-dimensional matrix containing all active dimensions across both rows and columns. The intersection cell between any two dimensions defines their mutual compatibility:

1. No limitation (blank): No restrictions. Any value of Dimension A can be combined with any value of Dimension B on the same document or journal line.
2. Blocked: Strict mutual exclusion. Dimension A and Dimension B cannot both be populated on the same transaction line. If a user enters values for both, posting fails: "Dimension [DEPT] cannot be used with Dimension [PROJECT]."
3. Limited: Granular partial restriction. Some values of Dimension A can be combined with Dimension B, while others are blocked.

Dimension Combinations Matrix (Page 538):

                 | DEPARTMENT | PROJECT    | AREA       | CUSTOMERGROUP |
-----------------+------------+------------+------------+---------------+
DEPARTMENT       |    ---     |  Limited   |    Open    |    Blocked    |
PROJECT          |  Limited   |    ---     |    Open    |     Open      |
AREA             |    Open    |    Open    |    ---     |     Open      |
CUSTOMERGROUP    |  Blocked   |    Open    |    Open    |      ---      |

The Dimension Value Combinations Matrix (Page 539)

When an intersection is marked Limited, clicking the Limited link opens the Dimension Value Combinations matrix. This page displays the specific dimension values of Dimension A on rows and Dimension Values of Dimension B on columns:

• Each individual cell is either left blank (that dimension-value pair is allowed) or set to Blocked.
• Example: Department PROD can be combined with Project MFG-RND, but Department PROD is marked Blocked when combined with Project MARKETING-CAMPAIGN.

---

4. Default Dimension Priorities & Conflict Resolution

In complex transactions, a single document line incorporates multiple entities, each with its own Default Dimensions. When these defaults conflict, Business Central relies on the Default Dimension Priorities engine to determine the winning value.

The Dimensional Conflict Dilemma

Consider a Sales Order line created for an enterprise customer:

• Customer Card (C10000): Default Dimension DEPARTMENT = SALES.
• Item Card (1900-S): Default Dimension DEPARTMENT = PROD.
• G/L Account (40100 Sales Revenue): Default Dimension DEPARTMENT = CORP.

Because a transaction line can only carry a single dimension value for the DEPARTMENT dimension, Business Central faces an unresolvable conflict: Should the line be tagged as SALES, PROD, or CORP?

Configuring Default Dimension Priorities (Page 584)

UI Navigation Path:
Tell Me (Alt+Q) -> Default Dimension Priorities

In the Default Dimension Priorities page, administrators establish a strict hierarchy for resolving conflicts:

The Priority Resolution Rule

Precedence Rule: Lowest Numerical Integer = Highest Priority (Priority 1 Wins)

Priority Configuration Example for DEPARTMENT Dimension:

Table ID             | Table Name    | Priority
---------------------+---------------+-----------
18                   | Customer      | 1   <-- HIGHEST PRIORITY (WINS)
27                   | Item          | 2
15                   | G/L Account   | 3   <-- LOWEST PRIORITY

In this configuration, when the sales order line is entered, Business Central compares the competing priorities. Because Table 18 (Customer) holds Priority 1, its default value (DEPARTMENT = SALES) overrides the Item and G/L Account defaults and populates the line.

What Happens if Priorities are Tied or Undefined?

Tie-break rule (quoted from Microsoft Learn, Work with dimensions to track and analyze data): "If you set up two tables with the same priority for the same source code, Business Central always selects the table with the lowest table ID."

Business Central does not raise a blocking "conflicting default dimensions" error when priorities tie. Separate the two cases:

1. Two tables share the same priority for the same source code. The tie resolves silently and deterministically in favour of the lowest Table ID. In the Customer (Table 18) versus Item (Table 27) clash above, a tie means Customer wins — not because it is the customer, but because 18 < 27. Nothing is blocked and nothing is logged, which is exactly why an untested priority setup can post months of entries under the wrong department before anyone notices.
2. No Default Dimension Priority rule exists for that dimension. With no priority record to consult, Business Central falls back to data-entry order. On sales and purchase documents it treats dimensions in the header as coming from the customer or vendor. If you add lines carrying an item default and then set a header field such as Location, Business Central asks you with a confirmation dialog whether to overwrite the existing lines — it does not abort the document.

[!IMPORTANT] The consequence of the lowest-Table-ID tie-break is that a tie is a silent misconfiguration rather than a loud one. Always assign explicit, distinct priority numbers, and test the setup using the same order of data entry your users actually follow.

---

5. Common Implementation Pitfalls & Exam Traps

• Pitfall 1: Confusing Code Mandatory with Same Code. Exam questions frequently describe a scenario where an account must have some department, but candidates mistakenly configure Same Code. Remember: Code Mandatory accepts any active dimension value, whereas Same Code strictly enforces the single specific code defined on the default dimension line.
• Pitfall 2: Creating Unpostable Deadlocks with No Code. If an administrator assigns No Code for DEPARTMENT on a revenue G/L Account, but a sales user creates an invoice for a customer configured with Same Code = SALES for DEPARTMENT, the document line cannot satisfy both rules simultaneously. Posting fails unless Default Dimension Priorities or line dimensions are explicitly reconfigured.
• Pitfall 3: Neglecting Default Dimension Priorities on Item Sales. Implementing default dimensions on Customers and Items without defining Default Dimension Priorities does not crash the document — and that is the danger. Business Central quietly applies the lowest-Table-ID default (Customer, Table 18, beats Item, Table 27) or keeps whatever the document header already supplied. The damage surfaces months later as thousands of ledger entries tagged to the wrong department, which then have to be repaired with the Dimension Correction Tool.
• Pitfall 4: Forgetting the Impact of Dimension Combinations. Setting two dimensions to Blocked in the Dimension Combinations matrix prevents any transaction from carrying both dimensions. If Customer defaults provide Dimension A and Item defaults provide Dimension B, the line cannot post.