Understanding Versions and Scenarios in Pigment

Versioning is a foundational concept in Pigment and in planning more broadly. While it has been referred to by many names throughout the history of Enterprise Performance Management—such as Scenario, Cycle, or Plan—in Pigment, we use the term Version to describe the structured planning cycles of your organisation: actuals, forecasts, and plans.

This article explains how Versions work, how to govern and freeze them properly, and where Scenarios fit in as a complementary tool.

The Version Dimension: The Core of Your Planning Architecture

Most Pigment Applications are built around Metrics structured by Dimensions. The fundamental rule is: all Metrics should have a Version Dimension.

This allows you to hold different sets of values for each planning cycle: Budget, Forecast, Reforecast, and Strategic Plan. The same inputs, formulas, and Boards are reused across all of them.

Typical examples of Version Items include:

• Budget FY26
• Forecast Q2
• Reforecast September
• Strategic Plan 3-Year

A Version is an official planning artifact designed to be repeatable, auditable, reportable, and governed.

Versions Across Multiple Applications

In Pigment's distributed planning model, you will typically manage several Applications: HUB, HR, Revenue, OPEX, Reporting, and others.

The recommended approach is to define your Version Dimension once in your HUB Application and share it across all other Applications. This ensures data flows seamlessly and all plans remain synced.

If a specific Application requires a different planning cadence. For example, if your Sales team runs 15 versions of a plan while the rest of the organisation runs only two, it is best to create a dedicated Dimension, such as "Revenue Version," for that App. You can then map this Dimension back to the main Version Dimension using a BY formula or a data import, so the right data still flows into your Reporting Application correctly.

Managing External Data Loads

Most external data is loaded into Transaction Lists, which are not versioned. To handle this, Pigment uses a switchover logic:

Each Version is assigned a last actual data date. Any data loaded after that date will not affect that version. For example, a Q1 Forecast dated April 1st will not be impacted by data loaded after that date.

You can also define different switchover dates for different data types, for instance, one date for accounting data and another for HR or headcount data.

Concluding a Planning Cycle: Snapshots and Clones

When a planning cycle is complete, two actions are needed:

1. Save the numbers
2. Initiate the next version

1. Save the Numbers: Snapshots

Pigment is a live calculation engine. Any change to inputs or formulas will immediately recalculate all live versions. The only thing that is truly fixed and unchangeable is a Snapshot.

A Snapshot preserves the state and data of up to five Applications at a specific point in time, even if the model evolves afterwards. The Snapshot includes all the Blocks, data, and Boards within the Application and functions as a read-only version once created. For more information, see Create and Manage Application Snapshots.

2. Initiate the Next Version: Cloning

Because Snapshots are frozen, you will also want to keep a live version of your numbers that can still be modified, for example, to reflect a reorganisation or transfer budget between departments.

To start a new cycle:

1. Take a Snapshot of the completed version.
2. Create a new Version Item in your Version Dimension, for example “Forecast M+1.”
3. Clone the data from the previous version, for example, “Board Plan Y+1,” into the new one.
4. Update the switchover date for the new version.

The original version remains live, allowing for future modifications when needed.

Adapting Formulas Across Versions

Because cloned versions are live, a formula change will immediately affect them. To manage this cleanly, create a Boolean setting on your Version Dimension, such as “Y+1 Logic Changes,” and structure your formulas with an IF statement:

IF(Y+1 Logic Changes,New formula, Old formula)

This makes it explicit which logic applies to which versions, and when changes were introduced.

Locking and Freezing Versions

Locking Inputs via Access Rights

Because Versions are full Dimensions, you can apply granular access rules:

• Set specific roles to Read / No Write on a given version.
• Control who can import, clone, or edit.

This is the recommended approach to preventing unintended changes to completed planning cycles.

Make It Permanent: Use Snapshots with Slices

It is important to understand that read-only does not mean truly frozen. Locking a Version prevents manual inputs and imports, but if underlying formulas change, historical results can still be recalculated.

The best-practice method for creating a permanent record of the data is to combine Snapshots with Slices:

1. Take a Snapshot of the approved version, for example, “Budget FY26 - Approved.”
2. Configure Slices in your Boards:
   • A Live slice pointing to the current working version.
   • A Frozen slice pointing to the Snapshot.

A typical setup looks like this:

This gives you stable, comparison-ready frozen data alongside a working version your team can continue modifying.

Where Scenarios Fit In

Scenarios are a complementary feature designed for speed and exploration, not for governed planning cycles.

Use Scenarios when you need fast, ad-hoc analysis without restructuring your model:

• Best case vs. worst case comparisons
• Sensitivity testing
• Short-term assumption testing
• Exploratory what-if analysis

Think of a Scenario as a temporary branch from your base case—useful for testing an idea, validating it in a meeting, and then deciding whether to incorporate it into the main Version model permanently.

Important Limitations to Keep in Mind

Scenarios do not have the full capabilities of a Version Dimension:

• Access rights are more basic. You can restrict Read/Write at the role level, but cannot apply granular, Dimension-level access rules.
• Modeling flexibility is more limited. Scenarios cannot be used the same way across all Blocks.
• Performance. Maintaining many active Scenarios can impact Application performance. They are designed for lightweight comparisons, not full planning architectures.

Summary