When we review a Workday Adaptive Planning model, Levels is one of the first areas we want to understand.
The screen looks simple.
There is a hierarchy on the left and Level Details on the right.
For each level we can see properties such as Code, Name, Display Name, Short Name, Rolls up to, Currency, Publish Currency, dependencies, and other settings.
But levels are not just another metadata list.
They represent one of the core structures of an Adaptive Planning model.
Workday describes levels as representing structures such as departments, profit centers, cost centers, or geographic regions. Every planning data point includes a level as part of its intersection with versions and accounts.
That makes level design important from the beginning.
If the level hierarchy is wrong, the impact can appear in planning, reporting, formulas, integrations, security, workflow, currency conversion, and historical data.
The question we ask is not simply how many levels should be created.
The better question is what organizational structure the planning model actually needs.
Understanding the Top Level
The screenshot shows Top Level.
Every Adaptive Planning model starts with a top level. Workday describes this as the ancestor of all other levels in the hierarchy. The top level does not roll up to another level, which is why the screenshot shows Rolls up to as None.
From there, child levels can be created underneath it.
A simple structure might look like this:
Top Level
North America
United States
Finance
Human Resources
Sales
Canada
Finance
Sales
Europe
United Kingdom
Germany
The actual hierarchy depends on the business.
It could represent companies.
It could represent cost centers.
It could represent departments.
It could represent regions.
In some models it represents a combination of organizational structures.
There is no single level hierarchy that is correct for every Adaptive Planning application.
Workday itself notes that model design needs to match the planning requirements and the structure of the business.
That is why we start with the business process rather than creating the hierarchy directly from whatever source data is available.
Levels form one hierarchy
A useful concept to understand is that the main Adaptive Planning level structure is hierarchical.
Each level rolls up to a parent, and ultimately the hierarchy rolls to the top level.
Workday uses terms such as parent, child, sibling, leaf level, and top level to describe the structure.
A parent level contains child levels beneath it.
A child level rolls into its parent.
Sibling levels share the same parent.
A leaf level has no children.
This is important because the hierarchy is not only for navigation.
It affects data aggregation.
For General Ledger accounts, Workday states that parent levels display values that sum their child levels. Other account types can have different level rollup behavior depending on account configuration.
So when we move a level from one parent to another, we are changing more than the appearance of the hierarchy.
We are changing where its values roll up.
Reparenting a level changes historical rollups
This is one of the areas where a small metadata change can have a large effect.
Suppose a Cost Center currently rolls into Operations.
The business reorganizes and wants that Cost Center to roll into Finance.
Changing the Rolls up to setting is technically straightforward.
But the reporting impact is larger.
Workday states that when the parent of a level changes, rollup values change, including in locked and archived versions. The underlying data and formulas remain with the level, but the level now contributes to the new parent hierarchy.
That means a hierarchy change today can change how historical results roll up.
This is something we want Finance to understand before making the change.
If the requirement is to show a new organization structure from a particular point in time while preserving an old historical organizational view, simply moving the level may not provide the desired result.
The business requirement needs to be clear first.
That is why we treat hierarchy changes as model changes, not just administrative maintenance.
Leaf levels are where data entry happens
Another useful concept is the distinction between parent and leaf levels.
A leaf level has no child levels.
Workday documentation states that data entry in sheets happens at leaf levels. Parent levels represent aggregated results rather than normal direct input points.
This affects how we think about planning grain.
If Finance wants users to enter expenses by Cost Center, those planning Cost Centers generally need to exist at the appropriate leaf level of the structure.
A hierarchy can still have multiple layers above them for management reporting.
For example:
Corporate
Region
Business Unit
Cost Center
The Cost Center may be the planning input level.
Business Unit and Region provide rollups.
Corporate provides the overall total.
This separation between input grain and reporting hierarchy is important.
We do not need to make every reporting node an input point.
The hierarchy can provide aggregation without requiring users to plan at every level.
The Only level is easy to overlook
Adaptive Planning also automatically creates an Only level for parent levels.
This is a useful concept when a parent itself needs to hold income or expense that does not belong to one of its child levels.
Workday explains that Only levels do not appear in the normal level hierarchy but can appear in sheets and reports.
For example, suppose Corporate has three departments beneath it:
Finance
Human Resources
Technology
There may also be a corporate expense that belongs directly to Corporate rather than any individual department.
The Only level can provide a place for that type of value.
This matters when reviewing reports.
Sometimes a parent total is higher than the visible sum of its children.
Before assuming the report is wrong, we check whether values exist at the parent Only level.
It is a small concept, but it can explain differences that otherwise look like calculation problems.
Code and Name serve different purposes
The Level Details screen shows both Code and Name.
These should not be treated as the same thing.
Workday defines Code as the unique identifier for the level and notes that the level code can be referenced in formulas. Name contributes to how the level displays throughout the model.
From an architecture perspective, we want level codes to be stable.
Descriptions and business names can change.
Identifiers should ideally remain consistent.
For example, a department may be renamed from Corporate Technology to Enterprise Technology.
If the underlying business object is still the same, changing the display name may be reasonable.
Changing the identifier can create more integration and formula considerations.
When Workday data is being integrated into Adaptive Planning, Workday also recommends using Workday IDs for level IDs and parent IDs in applicable metadata integrations.
This is a useful pattern because IDs are generally better integration keys than descriptions.
Names are for people.
Codes are for identification.
Keeping that separation clear makes metadata easier to support.
Display Name and Short Name are usability settings
The screenshot also shows Display Name, Short Name, and Display name format for levels.
These settings are easy to dismiss as cosmetic.
They are still useful.
Workday allows the top level to control how level display names appear across the model. The Short Name can be used in places such as dashboard charts where a shorter label is useful.
A hierarchy can become difficult to use when names are too long or inconsistent.
For example:
100420 Finance
100420 Corporate Finance
100420 Finance Department North America
Each may technically identify the same type of organizational object, but inconsistent naming creates confusion in sheets and reports.
We normally want a naming convention that works for planners and administrators.
The goal is not to make metadata look technical.
The goal is to make it easy to understand which level a user is selecting.
Levels and currencies are connected
The screenshot shows Currency as part of Level Details.
That is significant in a multi currency planning model.
Workday allows a currency to be assigned to a level. The top level uses the corporate currency. In multi currency models, child levels can use different local currencies.
Consider a model with entities in the United States, United Kingdom, and India.
The leaf levels might use:
USD
GBP
INR
The parent structure may report in another corporate currency.
Workday explains that when multiple currencies are configured, every level is assigned a currency and values can convert through the hierarchy as they roll up.
That means level hierarchy and currency architecture are related.
Moving an entity from one parent to another or assigning the wrong currency is not just a metadata problem.
It can affect translated reporting.
We therefore want currency assignment to be part of level validation whenever the model supports multiple currencies.
Publish Currency has a specific purpose
The screenshot also shows Publish Currency.
This is not simply another reporting currency setting.
Workday documents Publish Currency as a level setting available for instances configured with Workday Financials. It determines the currency used for that level when publishing a financial plan to Workday Financials.
That distinction matters.
Currency is part of the Adaptive Planning level itself.
Publish Currency relates to publishing financial planning information back into Workday Financials where that integration is configured.
We should therefore not populate Publish Currency just because it appears on the Level Details screen.
There should be a real integration requirement behind it.
Level availability is better than deleting old levels
Organizations change.
Cost centers close.
Departments are reorganized.
New legal entities are created.
Old entities stop being used.
A common question is what to do with an old level.
Deleting it may look like the cleanest option.
It often is not.
Workday provides level availability so a level can remain in historical versions while being unavailable in current planning versions.
This is particularly useful for preserving history.
Workday’s model design guidance specifically recommends using version availability when retiring levels rather than simply renaming them with text such as DO NOT USE. It also warns that deleting a level removes associated data across versions, including locked and archived versions.
That is an important operational rule.
If a Cost Center existed for three years but is no longer active, Finance may still need those three years of historical reporting.
Making it unavailable in the current plan can preserve that history without presenting it as a valid planning option.
That is normally much cleaner than leaving dozens of inactive levels available to planners.
A ragged hierarchy can be better than artificial levels
Not every branch of an organization has the same depth.
One region might have:
Region
Country
Division
Cost Center
Another might only need:
Region
Country
Cost Center
It can be tempting to create an artificial Division level in the second branch just so both structures look the same.
Workday recommends avoiding unnecessary one to one levels and supports ragged hierarchies where different branches can have different depths.
This is a useful architecture principle.
We do not need to create metadata just to make the tree look symmetrical.
Every extra level adds another object to maintain, integrate, secure, navigate, and report.
If a hierarchy node has no real business meaning, we question why it exists.
Use attributes when another hierarchy is not really required
Sometimes Finance wants to report on the organization in another way.
For example, the main level hierarchy may be based on Cost Center ownership.
Management may also want to group those Cost Centers by region.
That does not automatically require changing the main hierarchy.
Workday supports level attributes and level dimensions that can provide alternate grouping structures. Its model design guidance recommends considering level attributes first where they satisfy the requirement because they can provide a simpler approach than level dimensions in many cases.
This is one of the areas where we try to avoid over modeling.
The main hierarchy should represent the primary organizational planning structure.
Attributes can provide other classifications where needed.
We should not force every reporting requirement into the main level tree.
Levels also affect security
Levels are closely connected to Adaptive Planning security.
Workday supports level based security and access rules based security structures. In level based security, level ownership can determine which level data users can access. Access rule security can also use level hierarchy logic to define access to intersections of data.
Hierarchy design therefore affects more than financial reporting.
Suppose a regional finance manager needs access to an entire region.
Granting access to the appropriate parent level can provide access to descendants depending on the security structure and rules being used.
Workday notes that with access rule hierarchy logic, access to a parent includes descendants, while access to children does not automatically include ancestors.
This is why security should be reviewed when the hierarchy changes.
Moving a level can potentially change which rollup it belongs to.
That may also change which users can access the data depending on the security design.
We should not assume a hierarchy move is security neutral.
Levels are also integration objects
In larger Adaptive Planning environments, levels are often maintained through integrations rather than manually.
Workday provides a Planning Level Loader that can create and update level metadata from staged source data.
For Workday source integrations, Workday documentation notes that levels must load with their hierarchy path connected back to the root. Parent identifiers are therefore important, not just the level itself.
This is worth emphasizing.
A level integration is not simply:
Code
Name
It is closer to:
Level ID
Level Name
Parent ID
Currency
Attributes
Availability where applicable
Other relevant properties
The parent relationship is what builds the hierarchy.
If a source sends the wrong Parent ID, the level may exist but roll into the wrong part of the organization.
That can make the metadata load technically successful while the model is financially wrong.
This is why metadata integration needs reconciliation too.
After loading levels, we want to validate hierarchy counts, parent relationships, new levels, moved levels, missing levels, and the Top Level rollup.
A green integration status does not prove the hierarchy is correct.
Dependencies matter before making structural changes
The screenshot includes View Dependencies.
That is one of the most useful things to consider before changing metadata.
Levels can be referenced by formulas, sheets, reports, integrations, security, attributes, and other model objects.
Before deleting, moving, or significantly changing a level, we want to understand what depends on it.
This is especially important for long lived models.
A level created five years ago may no longer look important in the hierarchy, but it could still be referenced in a formula or historical report.
Checking dependencies before changing the structure is much easier than troubleshooting broken behavior afterward.
A note about the In Workflow setting
The screenshot shows an In workflow setting.
This is important because Workday’s workflow capabilities have changed.
In the legacy Workflow model, the level setting determines whether a level participates in the Workflow approval process. Workday documentation for level settings describes the top level as always included.
Workday introduced Configurable Workflows in the 2026R1 release. When Configurable Workflows are enabled, the legacy Workflow and Process Tracker functionality is disabled, and Workday removes the In workflow setting from the Levels page.
So if an environment still displays the field shown in this screenshot, the workflow configuration should be understood in the context of that tenant and feature setup.
We would not design a new workflow process based only on an older level setting without first checking which workflow framework is enabled.
What we check before changing a level hierarchy
When reviewing Levels, we normally want to answer a few basic questions.
What business structure does the hierarchy represent?
What is the source of truth?
Which levels are parents?
Which levels are planning input levels?
What are the stable identifiers?
How are inactive levels handled?
Are currencies assigned correctly?
Are attributes being used appropriately?
Which users receive access through the hierarchy?
How is the hierarchy maintained?
Are levels created manually or loaded through an integration?
What happens when the organization restructures?
Which reports and formulas depend on existing rollups?
These questions tell us whether the hierarchy is just working today or whether it can also be maintained safely.
What we try to avoid
We try to avoid copying an entire source organizational hierarchy into Adaptive Planning without first understanding what Finance needs.
We avoid using names as integration keys when stable IDs are available.
We avoid deleting historical levels simply because they are no longer active.
We avoid creating artificial levels just to make every hierarchy branch look identical.
We avoid changing parent relationships without understanding the historical reporting impact.
We avoid adding another hierarchy layer when an attribute would solve the reporting requirement.
We avoid assuming that a successful metadata load means the hierarchy is correct.
And we avoid treating Levels as an isolated administration area.
They are connected to almost everything else in the model.
Why level architecture matters
The Levels page shown in the screenshot contains only a handful of visible settings.
But those settings define a major part of how the Adaptive Planning model behaves.
Code identifies the level.
Name tells users what it represents.
Rolls up to places it in the organizational hierarchy.
Currency affects multi currency behavior.
Availability controls where the level is relevant.
Attributes can provide other ways of grouping it.
Security can use the hierarchy to control access.
Integrations can create and maintain the structure.
Formulas and reports can reference it.
Changing one of those relationships can affect much more than the Levels screen.
That is why we treat level design as architecture.
The goal is not to create the most detailed organization tree possible.
The goal is to create the organizational structure required for planning.
It should be detailed enough for Finance to plan and report correctly.
It should be stable enough for integrations and formulas.
It should support the required security model.
It should preserve historical reporting when the organization changes.
And it should be understandable by the administrators who will maintain it later.
If we can look at a level and clearly answer what it represents, where it comes from, why it rolls to that parent, who plans at it, which currency it uses, and how it should behave when it becomes inactive, then the level architecture is probably in good shape.
If those answers are unclear, the Levels page is a good place to start the review.
Official Workday References
Workday Adaptive Planning Levels
Workday Adaptive Planning Parent Levels
Workday Adaptive Planning Level Settings
Workday Adaptive Planning Level Availability
Workday Adaptive Planning Model Design Guidance
Workday Adaptive Planning Security and Level Hierarchies
Workday Adaptive Planning Metadata Integration Guidance
