When organizations start using Workday Adaptive Planning, the model is the first thing that matters.
The model is the backbone of everything you do in planning. It defines the structure, logic, dimensions, sheets, calculations, and the way data flows across finance, sales, workforce, operations, and reporting.
If the model is clean and well designed, every planning cycle feels more predictable.
If the foundation is weak, the system becomes harder to maintain over time.
Setting up Adaptive Planning is not just a technical exercise. It is the process of translating how the business actually works into a reliable, scalable planning structure.
That design decision affects every budget, forecast, scenario, report, dashboard, and integration that comes after it.
Start with the Adaptive Planning Instance
Every implementation begins with the Adaptive Planning instance and user access.
Once users sign in, they enter an empty but functional planning environment. Adaptive already includes the core structures needed to begin modeling financials, sales, workforce, and operational plans.
But the default environment is only a starting point.
The real value comes from how the model is designed.
Finance teams need to decide how the business should be represented, how data should roll up, how users should enter assumptions, how actuals should load, and how reports should tell the performance story.
This is where model design becomes finance architecture.
Understanding the Four Core Dimensions
Workday Adaptive Planning treats every number as a point in a planning grid.
That grid is built on dimensions.
Every instance includes four core dimensions that define how data behaves: time, versions, accounts, and levels.
These dimensions control where data sits, how it rolls up, how users interact with it, and how planning outputs are reported.
Getting these four dimensions right is the first step toward a scalable model.
Time
Time defines the calendar structure used for planning and reporting.
Adaptive Planning commonly starts with a standard January-to-December calendar using months, quarters, and years.
Finance teams can extend the calendar, add future years, and create alternate time rollups if the business uses different reporting cycles.
Time design matters because planning is not always the same as accounting close.
Budgets, rolling forecasts, workforce plans, revenue plans, and scenario models may need different time views. A strong model supports the reporting calendar while still giving FP&A enough flexibility to plan forward.
Versions
Versions organize the planning cycle.
Every Adaptive Planning instance starts with actuals and plan versions.
Actuals versions store historical results. Plan versions store budgets, forecasts, scenarios, and what-if models.
Teams can create additional versions for annual budgets, working forecasts, board forecasts, rolling forecasts, upside cases, downside cases, and strategic planning scenarios.
Version design is important because it controls how finance compares performance.
A clean version strategy helps users understand which version is current, which version is approved, which version is for scenario analysis, and which version should no longer be used.
Without version governance, planning environments become crowded and confusing.
Accounts
Accounts hold the financial and operational values in the model.
They form the foundation for the P&L, balance sheet, cash flow, KPIs, metrics, assumptions, and calculated outputs.
Adaptive Planning can support general ledger accounts, custom accounts, metric accounts, calculated accounts, modeled accounts, and assumption accounts.
This is where planning logic begins.
A good account structure should be easy to understand, aligned with reporting needs, and flexible enough to support driver-based planning.
The model should not simply copy every ERP account without considering planning purpose. The account structure should reflect how finance plans, analyzes, and explains performance.
Levels
Levels represent the organization.
They can reflect entities, departments, cost centers, regions, business units, subsidiaries, or any structure used to assign planning responsibility.
Levels are important because they drive ownership, access, workflow, reporting, and rollups.
A clean level hierarchy helps finance control who owns which part of the plan. It also makes approvals and reporting easier to manage.
A weak level structure creates confusion. Users may enter data in the wrong place. Reports may not roll up properly. Security becomes harder to manage.
The level hierarchy should reflect how the business manages responsibility, not just how accounting stores transactions.
Adding Custom Dimensions and Attributes
Most companies need more than the standard dimensions.
They may need to plan by product, customer, channel, region, project, contract type, vendor, initiative, or sales territory.
Custom dimensions add these extra coordinates to the model.
They allow finance teams to analyze performance across the business views that matter most.
Attributes provide another layer of flexibility. They help group accounts, levels, or dimension values without changing the main hierarchy.
For example, a product may have an attribute for product family. A level may have an attribute for region. An account may have an attribute for reporting category.
This flexibility is one of the reasons Adaptive Planning can support many planning processes.
But custom dimensions and attributes should be used with discipline.
Every dimension should have a clear planning or reporting purpose.
Building the Model: Where the Real Work Begins
Most model setup work happens in the modeling area of Adaptive Planning.
This is where finance and system owners configure the structure that users will later use for planning, forecasting, reporting, and analysis.
A good implementation follows a structured sequence.
The goal is not to build everything at once.
The goal is to design the model in the right order so the foundation can support future growth.
1. Review and Extend the Time Structure
The first step is to review the calendar and time setup.
Finance teams should confirm the fiscal year, months, quarters, years, planning horizon, and reporting needs.
If the business uses alternate rollups or special reporting periods, those should be considered early.
Time structure affects versions, sheets, reports, formulas, and integrations, so it should be designed carefully from the start.
2. Create and Configure Plan Versions
Next, finance teams define the version strategy.
Budgets, forecasts, and scenarios should each have a clear purpose.
For example, an annual budget version should be controlled and locked after approval. A working forecast version should be editable during the forecast cycle. A scenario version may be limited to FP&A or leadership users.
Each version follows the model structure but stores its own set of numbers.
Good version design keeps planning organized and prevents users from working in the wrong version.
3. Build the Level Hierarchy
The level hierarchy defines how the organization rolls up.
This may include companies, regions, departments, cost centers, business units, or operating groups.
The hierarchy should support reporting, access, workflow, and accountability.
Finance should avoid building levels only from a technical or ERP perspective. The structure should reflect how the business reviews and owns performance.
This is one of the most important design decisions in Adaptive Planning.
4. Add Custom Dimensions
Custom dimensions are added when the planning process needs more detail than time, version, account, and level.
Examples include product, customer, channel, project, initiative, location, sales territory, or vendor.
These dimensions should be designed around planning decisions.
If leadership reviews performance by product, product should be part of the model. If project profitability matters, project should be structured properly. If sales planning depends on territory, territory should be modeled intentionally.
The key is restraint.
Adding dimensions is easy. Maintaining them is harder.
5. Add Attributes
Attributes help finance group and analyze data without adding unnecessary hierarchy complexity.
They can be used to tag levels, accounts, or dimension values for reporting, filtering, formulas, or alternate views.
Attributes are useful when the business needs flexible grouping but does not need another full planning dimension.
A good model uses attributes to simplify reporting and reduce unnecessary structural complexity.
6. Build Accounts and Formulas
Accounts hold the data.
Formulas drive the logic.
Adaptive Planning supports several account types and calculation methods, including calculated accounts, shared formulas, modeled accounts, metric accounts, and assumption accounts.
This is where driver-based planning becomes possible.
Revenue can be calculated from volume and price. Workforce cost can be calculated from headcount, salary, start date, benefits, and taxes. Operating expenses can be calculated from usage, contracts, inflation, or activity drivers.
Centralized formulas keep the model consistent.
Instead of each user creating different logic in spreadsheets, Adaptive Planning allows finance teams to define logic once and apply it across the model.
7. Build the Right Sheets
Sheets are where users interact with the model.
Adaptive Planning supports three main sheet types: standard sheets, modeled sheets, and cube sheets.
Standard sheets are useful for account-based planning, such as general ledger planning, expense planning, and financial statement planning.
Modeled sheets are useful for record-based planning, such as workforce, sales, contracts, assets, projects, and operational drivers.
Cube sheets are useful for multi-dimensional planning where users need pivot-style input and analysis across several dimensions.
Choosing the right sheet type matters.
A workforce model should not be forced into a simple GL sheet if it needs employee or position-level records. A product revenue model may need cube functionality if it depends on product, customer, region, and channel intersections.
Good sheet design makes planning easier for users and easier to maintain for admins.
8. Link Operational Detail Back to the Financial Model
Detailed planning should connect back to the financial statements.
Modeled sheets and cube sheets often hold operational detail, but the final financial impact needs to flow into standard accounts.
For example, a workforce modeled sheet may calculate salary, bonus, benefits, and payroll taxes. Those outputs should link back to the P&L.
A sales planning model may calculate bookings, revenue, churn, and ARR. Those outputs should connect to revenue accounts and reporting views.
This connection keeps the financial model aligned with operational drivers.
Without it, finance ends up managing disconnected schedules again.
9. Load or Enter Data
Once the structure is ready, data can enter the model.
Data may come through direct entry in sheets, integration loaders, APIs, automated data agents, or connected source systems.
Actuals often come from ERP systems such as Workday Financials. Workforce data may come from HR systems. Sales data may come from CRM. Operational drivers may come from business teams or data warehouses.
The important point is that all data should land in the right structure.
A strong model does not just accept data.
It organizes data so finance can plan, forecast, analyze, and report with confidence.
Why Model Setup Matters
Model setup determines the quality of every planning cycle.
When the model is well built, planning becomes faster and smoother.
Approvals move more cleanly. Forecasts update with less manual work. Scenarios can be created faster. Reports tie back to the same model. Teams spend less time reconciling and more time analyzing.
When the model is weak, the opposite happens.
Users create offline workarounds. Formulas become difficult to maintain. Reports do not tie. Actuals do not load cleanly. Security becomes harder to manage. Scenarios take too long to build.
A strong Adaptive Planning model is not just a system setup.
It is a finance architecture decision.
It shapes how teams collaborate, how assumptions are managed, and how performance is explained.
What Good Adaptive Planning Model Design Looks Like
A strong model has clear signs.
The level hierarchy reflects ownership.
Accounts support both financial reporting and planning logic.
Versions are governed.
Sheets match the way users actually plan.
Custom dimensions support real analysis needs.
Attributes simplify reporting.
Formulas are centralized and explainable.
Actuals load cleanly from source systems.
Operational models connect to the financial statements.
Reports and dashboards are built from trusted structures.
Most importantly, finance users understand how the model works.
A good model should not feel like a black box.
It should make planning easier, not more confusing.
Common Mistakes to Avoid
Common model setup mistakes include copying ERP structures directly without planning design, adding too many dimensions, creating too many versions, building formulas in too many places, using the wrong sheet type, forcing operational planning into GL structures, ignoring security during design, and loading data before mappings are stable.
Another common mistake is treating the initial build as the final design.
Adaptive Planning models should evolve with the business, but they need governance so changes do not create model drift.
The goal is not to build the most complex model.
The goal is to build the model that best supports planning decisions.
How EPMLogic Supports Model Design
EPMLogic helps finance teams design Workday Adaptive Planning models that reflect how their business actually operates.
We help structure dimensions, build account logic, define formulas, create sheets, design versions, connect actuals, align operational drivers, and build reporting outputs.
Our goal is simple: create a clean, scalable model that finance teams can trust every planning cycle.
A strong model gives FP&A the foundation to plan faster, explain performance clearly, and support better business decisions.
Final Thoughts
Setting up Workday Adaptive Planning is more than configuring a system.
It is translating the business into a planning model.
The strongest implementations start with good structure: time, versions, accounts, levels, dimensions, attributes, formulas, sheets, and data flows all working together.
When that foundation is clean, planning becomes easier.
Forecasts become more reliable. Scenarios become faster. Reports become more trusted. Teams spend less time fixing the model and more time using it.
That is the real value of strong Adaptive Planning model design.