Versions look simple when we first open the Version Management screen in Workday Adaptive Planning.
The screenshot above shows the Add, Edit, or Delete Version page with an Actuals version selected.
At first, version management can look like basic administration. Create Actuals. Create Budget. Create Forecast. Give users access. Done.
In practice, versions affect much more than naming planning scenarios.
Versions control where different planning datasets live, which periods contain plan data, how Actuals can overlay a plan, who can edit the data, when a forecast should be locked, and how historical plans are preserved.
For us, version management is part of the planning architecture.
Before creating another Budget, Forecast, or scenario version, we want to understand why it needs to exist and how it will be used.
What a version represents
Workday defines a version as a financial scenario within an Adaptive Planning model.
Adaptive Planning supports Actuals versions and Plan versions. Although each version contains different data, the underlying account, level, and dimension structures remain part of the same model.
This is an important distinction.
A version is not another copy of the entire Adaptive Planning application.
If we have Actuals, Budget, Forecast, and Forecast Scenario 2, we are still working with the same model structure.
The versions provide different sets of data against that structure.
That is why version design is closely connected to the rest of the model.
If an account is added, a hierarchy changes, or a formula changes, we need to understand how that structural change may affect multiple versions.
We should not think about versions independently from accounts, levels, dimensions, sheets, and formulas.
Actuals and Plan versions solve different problems
The first distinction we normally make is between Actuals and Plan versions.
Actuals represents data that has already occurred.
Plan versions support planning scenarios such as budgets and forecasts.
The screenshot shows the Actuals version selected.
Workday documentation notes that most Adaptive Planning instances have one root Actuals version. Actuals can also support subversions, and journal entry versions are available for applicable consolidation use cases.
For a normal FP&A architecture discussion, the key point is simpler.
We normally want one clear place where actual historical results are represented and separate Plan versions for future planning scenarios.
For example, a model might contain:
Actuals
Budget 2027
Forecast Q1
Forecast Q2
Forecast Q3
Long Range Plan
Management Scenario
Those names are only examples.
The right structure depends on the planning process.
We do not recommend creating versions simply because someone wants another copy of the numbers.
There should be a business reason.
How many versions do we really need
This is one of the first questions we ask when reviewing an existing model.
It is common for version lists to grow over time.
A new forecast is created.
Then someone needs another scenario.
Then another forecast is created for a management review.
Then the previous forecasts remain because someone may need them later.
After several planning cycles, the version list can become difficult to understand.
That does not necessarily mean the model is badly designed.
Historical versions can be useful.
The issue is whether there is a clear version strategy.
We normally want to know which versions are active, which are historical, which are used for reporting, which are temporary, and which should no longer be visible to normal users.
Workday recommends organizing Plan versions using folders and keeping current versions easy for users to find. Workday also recommends reviewing version configuration as part of model design and performance management.
The objective is not to minimize the number of versions at all costs.
The objective is to make every version understandable.
If nobody can explain why a version exists, it is worth reviewing.
Budget and Forecast should have clear purposes
Budget and Forecast are often treated as interchangeable labels.
They usually are not.
A Budget version may represent an approved annual operating plan.
A Forecast version may represent the latest expected outcome using actual results through a completed period and planned values for future periods.
That distinction should be reflected in the version design.
For example, we may want a finalized Budget to remain stable for variance reporting.
The Forecast may continue changing every month or quarter.
Finance may then report:
Actual versus Budget
Actual versus Forecast
Forecast versus Budget
Current Forecast versus Prior Forecast
The exact reporting requirement should influence the version strategy.
Creating versions first and figuring out reporting later usually creates more work.
We prefer to understand the comparison requirements first.
Actuals overlay is one of the most important version concepts
One of the useful capabilities in Workday Adaptive Planning is the relationship between Actuals and Plan versions.
A Plan version can use Actuals as an overlay.
This matters for forecasting.
Imagine we are preparing a forecast during the year.
January through June are already complete.
July through December are still being forecast.
Finance normally does not want to manually copy January through June actual results into the Forecast version every time Actuals are updated.
Instead, the Plan version can display Actuals for the completed portion of the year and Plan data for the future portion.
The Start of Plan setting defines where Plan data begins and where the Actuals overlay stops for the Plan version. Workday also provides a Completed Values Through setting on root Actuals that influences where Actuals overlay ends.
This is a small configuration area with a significant planning impact.
When actuals overlay is configured incorrectly, users may think forecast data is missing or unexpectedly replaced by Actuals.
We always want to understand where Actuals ends and planning begins.
Start of Plan needs to match the process
The Start of Plan field deserves specific attention.
For a Plan version, this identifies when plan data begins.
Suppose Actuals are finalized through June.
If the forecast should begin in July, the Start of Plan should reflect that planning design.
As the year progresses, the boundary may move.
July becomes Actuals.
Then August.
Then September.
This sounds straightforward, but there are downstream questions.
When does Finance officially close the month?
When is the Actuals integration complete?
When should the forecast begin using the new Actuals period?
Who moves the boundary?
Does it happen manually or as part of a controlled planning process?
What validation happens before it moves?
Version management should align with the financial calendar.
Otherwise users can end up planning against a mixture of incomplete Actuals and forecast values.
The time range of a version matters
Plan versions also have time settings that determine how much information they contain and display.
Workday provides settings including Left Scroll Limit, Start of Plan, and End of Plan.
These settings should not be treated as arbitrary dates.
They influence how much historical and future planning data belongs in the version.
Suppose we have a rolling forecast.
We may need historical periods for comparison and future periods for planning.
That does not mean we need every historical year available inside every Plan version.
Workday recommends periodically reviewing the Left Scroll Limit because moving it forward can reduce version size and remove irrelevant historical periods from sheets. There are important data implications when changing this setting, so it needs to be handled deliberately.
From an architecture perspective, the principle is simple.
Keep the time range required by the planning process.
Do not keep unnecessary periods just because they were available when the version was originally created.
Creating a new forecast requires more than cloning
A common process is creating a new Forecast version from an existing version.
For example:
Forecast Q1 becomes the starting point for Forecast Q2.
The mechanics of copying a version are only part of the process.
We also want to decide what should actually carry forward.
Should all planning data copy?
Should formulas copy?
Should assumptions change?
Should the time horizon extend?
Should Actuals overlay move?
Should users retain the same access?
Should the prior forecast be locked?
These decisions should be part of the forecast cycle.
There is also an important detail when creating Plan versions.
Workday documentation notes that new Plan versions start as copies of the default version unless another source version is explicitly selected in the Start as copy of version setting.
That is the type of setting that can cause confusion.
Someone thinks they cloned the Forecast.
The resulting data does not look like the Forecast.
The first thing to check is which version was actually selected as the source.
We prefer to validate the new version immediately after creation instead of discovering the issue later in the planning cycle.
Locking a version is different from archiving it
Once a Budget or Forecast is finalized, we usually need to control what users can change.
Workday Adaptive Planning provides several version control options.
A locked version prevents users from changing data in sheets. Locked versions can remain visible for reporting and analysis.
This is useful when Finance wants to preserve an approved planning position.
For example, after the annual Budget is approved, Finance may lock that version so planners can no longer modify the numbers.
The Budget can still remain available for reports and variance analysis.
Archiving goes further.
Workday describes an archived version as a way to more completely freeze leaf level values so future model or formula changes are less likely to change the finalized result.
This distinction matters.
Locking primarily controls user changes.
Archiving is about preserving the finalized data more completely.
We should choose between them based on the requirement rather than treating the two options as the same thing.
Hidden is another separate control
Sometimes Finance does not want users to see a version at all.
Workday supports hiding versions.
When a version is hidden for a user, that version is not available to them in normal sheets, reports, and dashboards.
This can be useful for versions that are being prepared, administrative scenarios, or historical versions that should no longer appear in normal user selections.
Again, hidden and locked solve different problems.
Locked means the user can generally see the version but cannot change the data.
Hidden means the version is not available to that user in the normal planning experience.
We try to keep that distinction clear when designing access.
Version access is part of security design
Version security is another area we review carefully.
Workday provides version access controls with options such as Full Access, Import and Notes Only, Locked Except Notes, Locked, Visible, and Hidden depending on the version type and user category.
This gives administrators more control than simply editable or not editable.
For example, one group may need to enter forecast data.
Another may need to review it but not change it.
Another may only need reporting access.
Integration processes may also have different requirements from normal planners.
Version access should align with the planning operating model.
Who prepares the plan?
Who reviews it?
Who approves it?
Who can load data?
Who should only see finalized numbers?
We prefer to answer those questions before configuring version access.
Security becomes easier when it follows a clear business process.
Locking previous periods can also be useful
Not every planning process requires locking the entire version.
Sometimes the requirement is to prevent changes to earlier periods while future periods remain editable.
Workday provides a Lock Leading Months Through setting for Plan versions. The setting can lock completed time periods while later periods remain available for planning.
This can be useful in a rolling planning process.
For example, if January through March should no longer be editable, those periods can be controlled while the remaining forecast months continue to change.
The exact approach depends on how the planning process is governed.
The important part is that the version configuration reflects what Finance considers open and closed.
Historical versions still need governance
Keeping historical Budget and Forecast versions can be valuable.
They allow Finance to answer questions such as:
What did we expect three months ago?
How has the forecast changed?
What was the approved Budget?
How accurate was the prior forecast?
These are real analytical requirements.
But historical versions should not become an unmanaged collection of old plans.
We normally want a naming convention.
For example, forecast versions should be easy to identify by planning cycle.
Folders can help organize historical Plan versions.
Access should also be reviewed.
A version that was editable six months ago may no longer need to remain editable today.
The model should make it obvious which version is current.
Version management should follow the planning calendar
One of the easiest ways to improve version management is to connect it to the planning calendar.
For a forecast cycle, the process might include:
Actuals loaded and reconciled.
Completed period confirmed.
New Forecast version created or existing Forecast updated.
Actuals overlay moved.
Prior Forecast preserved.
New planning periods opened.
Version access reviewed.
Forecast completed.
Final Forecast locked.
Reporting refreshed.
The exact process varies.
What matters is that version administration does not happen randomly.
It should be part of the planning cycle.
This makes support easier because the team knows when version changes should happen and why.
What we check when reviewing version management
When we review an existing Workday Adaptive Planning application, we normally start with a few questions.
What is the root Actuals version?
Which Plan versions are currently active?
Which version is the approved Budget?
Which version is the current Forecast?
Which historical versions are still needed?
Which version is the default?
How is Actuals overlay configured?
Where does the current Forecast start?
What are the Left Scroll Limit and End of Plan settings?
Which versions are locked?
Which are archived?
Which are hidden?
Who has edit access?
How is a new Forecast created?
What happens to the previous Forecast?
These questions usually tell us more than simply counting the number of versions.
They explain how the planning process is operating.
What we would avoid
We try to avoid creating a new version for every small requirement.
We also avoid leaving temporary versions indefinitely without clear ownership.
We would not assume that locking a version completely freezes every possible effect of future model changes.
We would not move time settings without understanding the data impact.
We would not clone a Forecast without checking the source version.
We would not give broad Full Access simply because it is easier to configure.
And we would not delete or retire a historical version without first understanding whether reports, comparisons, integrations, or business processes still depend on it.
Most of these are not complicated technical rules.
They are basic planning governance.
The architecture is in how consistently they are applied.
Version Management is really scenario governance
The Add, Edit, or Delete Version screen looks like a small part of Workday Adaptive Planning.
But versions sit in the middle of the FP&A process.
Actuals provides the historical position.
Budget provides an approved planning baseline.
Forecast provides the latest expected outcome.
Historical forecasts preserve what Finance previously expected.
Scenario versions allow alternative assumptions to be evaluated.
Actuals overlay connects completed periods with future planning periods.
Access controls determine who can change each scenario.
Locking and archiving help preserve finalized plans.
Time settings control how much history and future planning belong in each version.
That is why we do not treat Version Management as basic administration.
We treat it as scenario governance.
A good version design should make it easy for a planner to answer three questions.
Which version should we use?
Which periods can we change?
What does this version represent?
If those answers are obvious, version management is probably doing its job.
If users regularly ask which Forecast is current, why one version has different Actuals, or whether an old Budget can still be changed, then the version architecture is worth reviewing.
The goal is not to build a complicated version structure.
The goal is the opposite.
Keep the structure clear enough that Finance understands exactly what each version represents and administrators understand how it should be maintained.
Official Workday References
Workday Adaptive Planning Versions
Workday documentation on Versions
Workday Adaptive Planning Plan Version Settings
Workday documentation on Plan Version settings
Workday Adaptive Planning Locked, Archived, and Hidden Versions
Workday documentation on version controls
Workday Adaptive Planning Version Access Control
Workday documentation on version access controls
Workday Adaptive Planning Model Design Guidance
Workday documentation on model design
