A practical design guide for model builders who want allocation models to answer not only what changed, but why it changed.
Author: Sripriya Rao is a Tech Lead at Prudential Financial and an Anaplan Solution Architect.
Audience: Model Builders, Solution Architects, CoE Teams
Quick takeaway: Accurate allocation results are not enough. A strong model should separate calculation from explainability, classify the drivers of movement, and provide a clear investigation path from summary to detail.
How to use this guide
Use this article as a design pattern when building or reviewing allocation models in Anaplan. The focus is not only calculation accuracy, but also how users understand the result, investigate movement, and build confidence in the model output.
As organizations expand their Connected Planning footprint, model explainability becomes increasingly important for building stakeholder trust, driving user adoption, and enabling confident decision-making across planning processes.
- For model builders: use the patterns to define comparison points, movement classifications, and reusable reporting outputs.
- For solution architects: use the structure to separate calculation logic from explanation logic and keep the model maintainable.
- For CoE teams: use the checklist and common mistakes section as a design review aid before publishing allocation results to business users.
The explainability architecture pattern
The central design pattern is simple: keep the allocation engine focused on producing accurate results, then use a separate explainability layer to classify and communicate movement. The reporting and UX layer should consume those explainability outputs rather than manually explaining variance after the fact.
Allocation Engine | → | Explainability Layer | → | Reporting / UX Layer |
|---|
Calculates final allocated values | | Classifies volume, rate, structural, and other impacts | | Presents KPIs, waterfalls, grids, and investigation views |
Core idea: Build explainability into the model architecture early. Do not treat it as a reporting enhancement added after the allocation engine is complete.
Part 1: Why explainability matters
Allocation models are often judged by whether the numbers calculate correctly. In practice, users usually ask a different question: “Why did my numbers change?” A model that produces accurate results but cannot explain them can still create frustration, reconciliation effort, and low user confidence.
A traditional allocation output may show the final result by recipient, service, cost center, product, channel, or another reporting dimension.
Cost Center | Allocated Cost |
|---|
Sales | $2,500,000 |
Operations | $3,200,000 |
Marketing | $1,100,000 |
This view is useful, but it does not answer the most important business questions:
- Why did Sales increase?
- What changed from the previous cycle?
- Was the increase caused by usage, rate, or allocation structure?
- Which specific relationship changed?
Design principle: Explainability closes the gap between model output and business understanding.
Common sources of allocation movement
Most allocation variance can be grouped into a few practical categories. Use driver categories that business users naturally understand. If the labels are too technical, the reporting layer may still be accurate but not explanatory.
Variance Driver | What it means | Examples |
|---|
Volume impact | The allocation driver changed. | Headcount, transactions, consumption, storage, service usage, seats, tickets |
Rate impact | The amount being allocated changed. | Vendor cost, service cost, labor cost, infrastructure cost, pool amount |
Structural impact | The relationship path changed. | New relationship, removed relationship, modified assignment, reclassification |
Mix or other impact | The change is driven by a combination or residual logic. | Model-specific adjustment, rounding, timing, or scenario-specific movement |
Part 2: How to design for explainability
Design principle 1: Separate calculation from explainability
A common mistake is attempting to embed every explanation directly inside the allocation calculation logic. This can make formulas harder to maintain and harder to validate.
A cleaner pattern is to keep the allocation engine focused on calculating results, then build a separate explainability layer that classifies and reports the movement.
Benefit | Why it matters |
|---|
Cleaner formulas | Core allocation logic stays focused on calculating results. |
Easier validation | Calculation and explanation can be tested separately. |
Reusable outputs | The same explainability outputs can feed grids, waterfalls, KPIs, exports, and UX pages. |
Improved flexibility | Business users can request different explanation views without forcing major changes into the allocation engine. |
Design principle 2: Track structural changes explicitly
Structural movement is often the hardest question to answer because it is not always visible in totals. A relationship may be added, removed, or modified even when the overall allocation still reconciles.
Important distinction: Structural change is not the same thing as value movement. A value can move because the driver changed, because the rate changed, or because the allocation relationship itself changed.
Classification | Typical logic pattern | Business interpretation |
|---|
New | Current relationship exists and prior relationship did not exist. | A new allocation path was introduced. |
Removed | Prior relationship existed and current relationship does not exist. | An existing allocation path was removed. |
Modified | Relationship still exists, but a key attribute, owner, mapping, or assignment changed. | The allocation structure changed without being fully new or removed. |
Design principle 3: Build waterfall-ready outputs
Waterfall reporting is one of the clearest ways to communicate allocation movement. However, the waterfall should be backed by model outputs, not manually explained after the fact.
Bridge Component | Purpose |
|---|
Prior allocation | Starting point for comparison |
Volume impact | Movement caused by driver usage or quantity changes |
Rate impact | Movement caused by cost pool or rate changes |
New relationships | Movement caused by new allocation paths |
Removed relationships | Movement caused by removed allocation paths |
Modified relationships | Movement caused by changed assignment or mapping logic |
Current allocation | Ending point after all components |
Builder tip: Design reporting line items and saved views so the bridge components are produced by the model. Avoid relying on manual commentary to explain the waterfall after results are published.
Part 3: How to present explanations to users
Create an investigation path in UX
Explainability should not overwhelm users with every detail at once. A better UX pattern is progressive disclosure: summarize first, show the main drivers next, and provide detailed investigation only when needed.
Level 1: Executive summary | Level 2: Driver breakdown | Level 3: Detailed investigation |
|---|
What changed overall? | Why did it change? | Where did it change? |
Current allocation, variance, top driver KPIs, and overall status | Volume, rate, structural, and other impacts by major reporting dimension | New, removed, and modified relationships with source-to-target traceability |
Implementation checklist
Use this checklist before finalizing an allocation model design, especially if the model will be used by business users who need to explain results, not just review them.
- Can users compare prior and current allocation results at the right grain?
- Are volume, rate, and structural impacts separated instead of blended into one variance?
- Are new, removed, and modified relationships classified explicitly?
- Can the same classification be used in grids, filters, KPIs, and waterfall reporting?
- Is the explainability layer separated from the core allocation calculation layer?
- Does the UX provide a clear path from summary to detail?
- Can users trace a variance back to the driver, rate, or relationship that caused it?
Common mistakes to avoid
Mistake | Why it causes issues | Better pattern |
|---|
Adding explainability after the model is complete | The required comparison points may not exist at the right grain. | Design explainability requirements early. |
Mixing calculation logic and explanation logic | Formulas become harder to test and maintain. | Use separate calculation and reporting/explainability layers. |
Reporting only total variance | Users still have to investigate manually. | Break variance into driver categories. |
Treating structural changes as miscellaneous variance | Relationship changes become hidden. | Classify new, removed, and modified relationships explicitly. |
Showing too much detail on the first UX view | Users may miss the main message. | Use progressive disclosure from summary to detail. |
Lessons learned
- Users trust explanations more than calculations.
- A correct number that cannot be explained is often treated as an incorrect number.
- Structural changes often drive the hardest business questions, so track them explicitly.
- Waterfall-ready outputs are easier to build when explainability is designed into the model architecture.
- The best allocation models do not just calculate the answer; they help users understand the answer.
Five design principles for explainable allocation models
Publication-ready summary: Design explainability early. Separate calculation logic from explanation logic. Classify movement into business-friendly drivers. Track structural changes explicitly. Give users a guided investigation path from summary to detail.
Final thought
As allocation models become more sophisticated, the challenge is no longer only producing accurate allocations. The challenge is making those allocations understandable.
By separating explainability from calculation logic, tracking structural changes, and designing investigation-friendly reporting, model builders can create solutions that improve transparency, accelerate analysis, and build user trust.
Discussion prompt
For the Anaplan Community: What is the most common allocation question your users ask after seeing the results: “what changed?”, “why did it change?”, or “where did it change?”
