An Introduction to Level Structure in Workday Adaptive Planning

In Adaptive, Levels represent the “hierarchy” of your organization.

Your organization can consist of various elements, such as subsidiaries, functions (R&D, G&A, S&M…), departments (HR, Finance, Engineering, Customer Support…), line of businesses (e.g. Ambulatory services, Imagery, Hospital…), Geographic regions, etc.

Levels can also be defined by your entities, or projects and missions if you are a non-profit organization.

Your level structure can also be a combination of several categories (e.g. Your level will be a mix of Entity + Region + Department).

Levels are one of the four foundational elements of Adaptive (along with Accounts, Versions, and Time).

Here is the link to the official documentation about levels.

Top Level and Examples

Every instance has a top level that aggregates data from all the levels. It essentially carries a consolidated view. You can then have rollups underneath based on the various elements that make up the level structure.

Quick note: in Adaptive, currencies are held by the Level.

Here is an example of a clean level structure for a typical SaaS company:

  • Company_XYZ_Consolidated (Top Level)
    • G&A
      • 001 Facilities
      • 100 Executive
      • 200 People
      • 300 Finance 
      • 350 Accounting
    • S&M
      • 400 Sales
      • 500 Marketing
      • 600 Business Development
      • 650 Public Relations
    • R&D
      • 700 Engineering
      • 800 Analytics
      • 850 Quality and UX
    • OTHER
      • 900 Professional Services
      • 950 Customer Support

Example of a level structure for a Non-Profit organization:

  • ORG_XYZ_Consolidated (Top Level)
    • Overhead
      • 001 Board of Directors
      • 100 HR
      • 200 Finance and Accounting
      • 300 PR and Communications
      • 400 IT
      • 500 Volunteers
    • Foundation
      • 1000 Northern California Food drive
      • 2000 Christmas Kids 
      • 3000 CA Housing
      • 4000 Smile for Seniors
      • 5000 Healthcare for Everyone
      • 6000 Homework Help
      • 9000 Donations
      • 9500 Board Sponsorship

Another, more granular, example of a SaaS company level structure ↓↓↓ Go down below – Click here ↓↓↓

Quick tips about your level structure

  • Keep it logically organized by geography, by alphabetical/numerical order, by function, etc.
  • Keep the code of your levels short and more generic vs. the name that can be longer and specific.
    • Levels in Adaptive have a code and a name. Code (like an ID) is typically used in formulas and it is thus best to keep it generic, rather than specific. Ideally, the code should never change. Name on the other hand is what you will see displayed in reports and it could (should) be more specific. The name can be updated should a change occur!
    • For example:  you have a level called “820 – Human Resources”.
      • Your level code should be 820 
      • Your level name could be: “820 – Human Resources” 
      • Later on, your department had a name change and became “820 – People Operations”. Your code will remain 820. And if it was used in formulas, you have nothing to worry about.. And you can simply update your level name to your new naming convention.
  • Ideally, you should have a clean structure that is aligned across systems (ideally!)
    • If your source systems (ERP for example) don’t have a clean structure, you can always have it structured differently in Adaptive (to meet your reporting needs).
    • You don’t necessarily have to align it with a 1 to 1 relationship with your accounting or source structure. You can ignore intermediary levels and instead group them in Adaptive leveraging Level Attributes.
      • Level attributes are basically “groupings”. They allow you to categorize, filter, and group levels in a way that aligns with your specific business needs and create an alternate hierarchy.
      • Link to official documentation about level attributes here.

Levels and Dimensions

Another good practice to keep in mind is that your level structure should rarely change or should not require constant additions (unless you add a new entity, a new location, a new mission, etc.).   However, if this is something that constantly needs reshuffling or new additions… What you probably need is a dimension!


For example, if you are a charity organization and you keep adding and retiring projects related to your missions… Typically projects would be a dimension.

For example under your mission level “CA Housing” you will have several projects (dimension values), such as “Sacramento Housing”, “San Francisco Housing”, “San Jose Housing” etc. Which may come and go over time!

Thus, these projects should not be part of your level structure as they could even be cross functional / departmental / GL Account when you book or forecast things.

Things to Remember

Keep your levels neat and clean:

  • organized and in some kind of order
  • with a consistent naming convention
  • generic code convention
  • check for redundancies (always question if it should be instead a dimension or a GL account)
  • leverage level attributes to group and tag your levels (to get easy pivots and consolidated views from various angles)

By organizing information in this way, you can achieve better data integrity, ease of maintenance, and adaptability to changes. Reporting + reconciliation will also be a breeze!

Bonus example – more granular level structure

Typical SaaS company structure

Here levels are a mix of : Function, Department, Legal Entity

Click Here to Learn More