Workday Adaptive Planning Level Attributes: Configuration, Reporting and Practical Examples

Level Attributes in Workday Adaptive Planning allow us to group existing organizational levels in different ways without changing the main level hierarchy.

We commonly use them when Finance needs to report by company, region, cost center group or functional team.

For example, the planning model may contain departments organized under different companies. Management may also want to view the same departments by function.

We do not necessarily need to create another hierarchy or custom dimension for this requirement.

A Level Attribute may be enough.

In this article, we look at how Level Attributes work, how we configure them, and how they are used in reporting, sheets, integrations and model maintenance.

1. What are Level Attributes?

We access Level Attributes from:

Modeling → Level Attributes

The Level Attributes option is also available in the Levels and Dimensions section of Model Management.

The screenshot shows three attributes:

These are names configured in the model. Their actual values and business use need to be verified separately.

A Level Attribute contains attribute values.

For example, a FunctionalTeam attribute might contain Finance, Technology, Operations and Sales.

We then associate those values with the appropriate levels.

Workday Adaptive Planning uses the associations to group the levels and their related data in reports.

2. Why do we need Level Attributes?

Let’s consider a simplified organizational hierarchy.

Top Level
├── Company A
│   ├── Finance A
│   ├── IT A
│   └── Operations A
└── Company B
    ├── Finance B
    ├── IT B
    └── Operations B

This hierarchy works for planning by company.

Each department enters its budget under the appropriate company.

Company A and Company B provide the organizational rollups.

Now suppose Finance wants to review the total Finance department cost across both companies.

The primary hierarchy does not directly provide a Finance parent containing both departments.

We could use a Level Attribute named FunctionalTeam.

We assign the following values:

The main hierarchy remains unchanged.

However, we can now report by FunctionalTeam.

This provides another way to analyze the same planning data.

3. How do Level Attributes work?

A Level Attribute describes a level.

It does not create another independent planning-data intersection.

For example, assume we have:

The financial data belongs to Finance A.

FunctionalTeam classifies Finance A as Finance.

When we enter data at Finance A, the associated Level Attribute applies automatically.

We do not need to select Finance again on every data-entry sheet.

This distinction is important when comparing Level Attributes with custom dimensions.

4. Creating a Level Attribute

Suppose we want to create a new Level Attribute called Business Function.

We navigate to:

Modeling → Level Attributes

We then:

1. Select the option to create a Level Attribute.
2. Enter the Code and Name.
3. Configure the display name format.
4. Review the sorting and automatic value creation options.
5. Save the attribute.

The attribute configuration includes the following settings.

The available settings are documented by Workday and may depend on the attribute type.

Code and Name

For example:

• Code: BUSINESS_FUNCTION
• Name: Business Function

We use the code as the technical identifier.

The Name provides the business label.

Workday supports referring to attribute codes in applicable formulas.

5. Creating Attribute Values

After creating Business Function, we need to create its values.

We select the attribute and use the toolbar option to create an attribute value.

For example:

Each value belongs to the Business Function attribute.

Workday also allows attribute values to be organized hierarchically.

For example:

Business Function
├── Corporate
│   ├── Finance
│   └── Human Resources
└── Operations
    ├── Manufacturing
    └── Supply Chain

This is an example of an attribute value hierarchy, not a change to the primary level hierarchy.

The hierarchy allows the attribute values to have their own reporting rollups.

6. Assigning Attribute Values to Levels

Creating the attribute and its values does not automatically classify every existing level.

We need to associate the attribute values with the appropriate levels.

To do this, we navigate to:

Modeling → Levels

We then:

1. Select the level.
2. Expand Level Attributes in the details panel.
3. Select the appropriate attribute value.
4. Save the changes.

For example, we select Finance A and assign:

Business Function = Finance

We repeat this for the other required levels or use a supported bulk update.

What happens when we tag a parent level?

Workday documents that when we assign an attribute value to a parent level, its child levels automatically inherit that value.

For example:

Company A → Company A Attribute
    Finance A → Company A Attribute
    IT A → Company A Attribute

If child levels need different attribute values, we must design the parent tagging and attribute value hierarchy accordingly.

Workday supports leaving the parent unclassified or using compatible hierarchical attribute values.

We should check this before assigning attributes at a high organizational level.

7. Scenario 1: Reporting expenses by Functional Team

Suppose we have the following expense data.

All amounts are illustrative and in the same reporting currency.

The primary hierarchy reports by company.

Using FunctionalTeam, we can report:

We are reporting the same underlying data.

We have not duplicated the values or moved the departments to another parent.

This is one of the main benefits of Level Attributes.

8. Scenario 2: Using Level Attributes in reports

Workday Adaptive Planning matrix reports support Level Attributes as report elements.

For example, we may want to display:

• FunctionalTeam on rows
• Account on columns
• Version as a filter
• Time as a filter

The report can then display expenses grouped by FunctionalTeam.

We can also use Level Attributes to create alternate reporting structures across departments that belong to different parents.

What happens if a level has no attribute value?

Workday groups untagged levels under Uncategorized in the alternate attribute hierarchy.

For example, if IT B is not assigned a FunctionalTeam value, its expense may appear under Uncategorized rather than Technology.

This is why we validate attribute assignments when a report total does not match the expected group.

9. Scenario 3: Level Attributes in cube and modeled sheets

Level Attributes are also supported in cube and modeled sheets.

They can help filter the levels available to users.

For example, suppose a cube sheet contains cost centers from several business functions.

We can configure a FunctionalTeam attribute for filtering.

When the user selects Finance, the level selection can be restricted to levels tagged with Finance.

This makes large sheets easier to navigate.

Can users change the attribute from the sheet?

Level Attributes are metadata classifications.

Workday documents that a Level Attribute value is read-only when displayed on the sheet.

To change the actual assignment, we update the level’s metadata rather than overriding the attribute on an individual transaction.

Partial rollups in cube sheets

Workday also documents partial attribute rollups in cube sheets.

If the sheet makes only selected attribute values available, an attribute rollup may include only those selected values.

We therefore check the attribute values available on the cube when a displayed total is smaller than expected.

10. Scenario 4: Level Attributes and integrations

Many organizations maintain levels through integrations from Workday or another source system.

Workday Adaptive Planning supports associating attributes with levels using a Planning Level Loader.

For example, an integration source may contain:

The level loader can map the Function value to an existing Level Attribute.

This allows us to maintain both the organization hierarchy and its classification through integration.

What about new attribute values?

The Level Attribute configuration includes an option to create attribute values automatically during supported level imports.

If the source contains a new value and automatic creation is enabled, the import can create the new attribute value.

We should only enable this when the source values are controlled.

For example, two source values such as Technology and Technlogy should not create two business classifications because of a spelling error.

11. Scenario 5: Level Attributes in Actuals and Plan versions

Levels are shared model metadata.

A level can be associated with the same Level Attribute when we view its data in Actuals, Budget or Forecast versions.

For example:

Finance A → FunctionalTeam = Finance

We can use the classification to group Finance A data in:

• Actuals
• 2027 Budget
• 2027 Forecast

The financial values differ by version, but the level classification remains part of the shared metadata.

Important consideration for historical reporting

If we change a level’s attribute assignment, this can change how existing data is grouped in attribute-based reports.

For example, if a cost center changes from Operations to Technology, historical results may appear under the new classification when reports use the current attribute assignment.

This matters when management needs historical organizational reporting.

We need to decide whether reporting should follow the current organization or preserve an earlier classification.

Level Attributes do not independently provide version-specific historical membership.

If the business requires different classifications over time, we evaluate the appropriate reporting and model design before making changes.

12. Level Attributes versus Level Dimensions

Workday supports both Level Attributes and Level Dimensions.

They can provide alternate organizational reporting views, but they behave differently.

Workday’s model design guidance recommends considering Level Attributes before Level Dimensions where the requirement can be met with attributes.

For example, if Finance only needs to group departments by business function, a Level Attribute may be sufficient.

If Finance needs to enter and maintain different values at multiple dimension intersections within the same organizational level, a custom dimension may be more appropriate.

The choice depends on how the data needs to behave, not just how it needs to appear in a report.

13. Scenario 6: Level Attributes and access rules

Workday Access Rules can use Level Attributes.

For example, an organization may use a Region Level Attribute to support region-based access rules.

This can simplify rule maintenance when many levels belong to the same region.

However, assigning an attribute does not automatically grant or restrict user access.

The actual access depends on the configured security rules.

If an attribute is used in security, we review the impact before changing its values or level assignments.

14. Importing multiple Level Attributes

For a small model, we may create attributes and values manually.

For a larger model, Workday supports spreadsheet imports.

We navigate to:

Modeling → Level Attributes

We can download a template or export the existing structure, update the file and import it.

Workday provides two important import options.

Workday recommends Update and append for normal changes.

Reloading attributes can require us to reassign metadata tags and restore references in sheets and reports.

We therefore review the import type before making bulk changes.

15. What happens when we delete a Level Attribute?

Deleting an attribute is different from deleting a custom dimension.

Workday documents that deleting attributes does not delete the underlying financial data.

However, the attribute and its values are removed from the model.

This can affect:

• Level classifications
• Reports
• Formulas
• Charts
• Sheet configuration
• Security logic that relies on the attributes

If an individual attribute value is deleted, its tags may move to the parent attribute value or Uncategorized, depending on the value hierarchy.

We use View Dependencies and review the downstream design before deleting or restructuring existing attributes.

16. What we check when Level Attributes do not work as expected

When an attribute-based report or sheet produces unexpected results, we review the following.

We first verify the metadata classification.

We then check how the report, sheet or formula uses it.

This helps us distinguish between an attribute configuration issue and an issue with the underlying financial data.

17. Summary

Level Attributes provide a way to classify existing levels without changing the primary organizational hierarchy.

They are useful for:

• Alternate reporting structures
• Grouping departments and cost centers
• Simplifying supported formulas
• Filtering levels in cube and modeled sheets
• Maintaining classifications through integrations
• Supporting attribute-based access rules

We create the attribute, define its values, assign those values to levels and then use the classification in reporting or other supported model functionality.

When designing a model, we first determine whether the requirement is only to group existing levels or whether it needs another independent planning dimension.

If the requirement is classification, we consider Level Attributes before introducing additional dimensions.

This keeps the organizational model easier to understand and maintain