Security in Workday Adaptive Planning can look complex on paper, but the concept is simple.
You decide who can see what, who can edit what, and how different parts of the model expose data to different users.
Every control matters: levels, versions, accounts, sheets, permissions, access rules, and user groups. Together, these layers protect planning data and make sure users only work with the parts of the model that are relevant to their role.
When teams understand how these layers fit together, Adaptive Planning becomes easier to govern. Finance stays in control. Admins reduce the risk of accidental exposure. Users get access to the data they need without seeing sensitive information they should not have.
A strong security model is not only an admin setup. It is part of the FP&A operating model.
Why Security Matters in Workday Adaptive Planning
Workday Adaptive Planning often contains sensitive finance data.
This can include salary detail, bonus assumptions, workforce plans, department budgets, forecast scenarios, actuals, management reporting, and confidential planning versions.
If security is weak, users may see information outside their role. They may edit data that should be locked. They may access versions that are still in review. They may view salary detail or sensitive accounts that should be restricted.
If security is too restrictive, the opposite problem happens. Users cannot enter plans, reports do not work, sheets appear incomplete, and admins spend too much time troubleshooting access issues.
Good security creates balance.
It protects sensitive data while allowing planning teams to do their work.
Two Main Security Structures
Workday Adaptive Planning supports two common approaches to data security: level-based security and access-rule security.
Each approach controls how users access planning data, but they work differently.
The right choice depends on how your organization manages access, how complex your model is, and how granular your control needs to be.
Level-Based Security
Level-based security is the simpler model.
Users can see and work only with the levels they own. This works well when your planning process follows a clear organizational hierarchy.
For example, a department manager may own one cost center. A regional finance lead may own several regional levels. A business unit owner may see only the levels under their area.
This model is clean and easy to explain.
It works well when reporting lines match planning ownership and when users do not need complex cross-dimensional access.
Many FP&A teams start with level-based security because it mirrors the cost center or department hierarchy.
The limitation is flexibility.
Level-based security is not always enough when users need access based on combinations of levels, accounts, custom dimensions, products, territories, or other planning intersections.
Access-Rule Security
Access-rule security gives administrators more granular control.
Instead of only assigning users to levels, access rules can define what users can view or edit across specific intersections of data.
For example, access can be controlled by level and account, level and custom dimension, territory and product, or other relevant combinations.
This is useful when planning ownership does not follow a simple hierarchy.
For example, an HR user may need access to workforce data across multiple departments but not all financial accounts. A sales operations user may need access to revenue planning by territory and product. A finance analyst may need edit access to forecast inputs but only view access to actuals.
Access rules are more flexible, but they also require stronger governance.
Most mature Adaptive Planning environments eventually move toward access rules because they provide better control and reduce manual ownership work as the business grows.
Security Is a Stack, Not a Single Setting
No matter which structure you choose, security in Adaptive Planning is not controlled by one switch.
It is a stack.
Credentials control who can enter the system.
Permissions control what areas of the system users can access.
Access rules control what data users can see or edit.
Levels control organizational visibility.
Versions control which planning cycles users can view, edit, or lock.
Accounts control whether sensitive data can be referenced or displayed.
Sheets control where users can enter or review data.
All of these layers work together.
Most security issues happen when one layer is set correctly but another layer blocks or exposes access unexpectedly.
For example, a user may have access to a level but not the version. Another user may have access to a version but not the account. A planner may be able to open a sheet but not edit the data because the version is locked or the account is read-only.
Understanding the full security stack makes troubleshooting much easier.
Credentials and Authentication
Credentials are the foundation of access.
Users sign in with a username and password or through single sign-on, depending on the organization’s setup.
This only controls entry into the system.
After the user is authenticated, Adaptive Planning still needs to determine what the user can do and what data they can access.
That is where permissions, access rules, levels, versions, accounts, and sheets come in.
Permissions
Permissions define what users can do inside Adaptive Planning.
They control access to areas such as sheets, reports, dashboards, modeling, administration, integrations, and other system functions.
A user may have permission to open reports but not edit sheets. Another user may have permission to manage versions but not administer model structure. An admin may have broader permissions across the environment.
Permission sets should be designed by role.
Common examples include administrator, FP&A analyst, department planner, executive viewer, HR planner, and report consumer.
The goal is to give users enough capability to perform their work without giving unnecessary access.
Access Rules
Access rules control what data users can view or edit.
This is where most of the detailed security behavior lives.
Access rules can secure intersections such as level and account, level and custom dimension, territory and product, or other model combinations.
For example, a finance analyst may be allowed to edit operating expense accounts for assigned departments but only view salary accounts. A regional manager may view revenue by region but not edit corporate assumptions. An HR partner may access workforce planning data across multiple departments but not broader financial planning accounts.
Access rules are powerful because they reflect how planning responsibility actually works.
But they need careful design.
If rules overlap, conflict, or are not documented, security becomes difficult to manage.
Level Settings
Levels can also be visible or hidden depending on version setup and planning requirements.
This is useful when certain levels should not participate in a specific planning cycle or when historical structures need to be preserved without exposing them in current planning.
Level visibility matters because users may have permission to access the system but still not see certain levels in a given version.
This is one reason security testing should include version, level, sheet, and account combinations.
Version Settings
Version settings are essential for planning governance.
Versions can be hidden, locked, editable, or restricted based on user type and process stage.
For example, actuals should usually be protected so only specific users can edit them. Approved budget versions should be locked after sign-off. Working forecast versions may be editable during the forecast cycle. Scenario versions may be available only to certain FP&A users.
Version access protects the planning process.
Without clear version controls, users may edit approved data, report from the wrong version, or see scenarios that are not ready for broader review.
A good security model should always align with the version strategy.
Account Settings
Accounts can carry important security behavior.
Two account-level settings that matter in many implementations are data privacy and salary detail.
Data privacy helps control how data can be referenced across levels. This is important when formulas or reports could expose values from levels a user should not access.
Salary detail protects compensation-related data so only approved users can see sensitive workforce information.
These settings are especially important in workforce planning models.
Salary, bonus, merit, benefits, payroll taxes, and employee-level assumptions often require stronger controls than standard operating expense accounts.
Sheet Settings
Sheets provide the final guardrails for user interaction.
A sheet can be marked read-only. It can be hidden from sub-levels. Cube intersections can be restricted. Salary detail sheets can be protected. Certain sheets can be exposed only to the right user groups or planning roles.
This matters because sheets are where many users interact with the model.
Even if permissions and access rules are correct, a poorly configured sheet can create confusion. Users may see too much detail, edit the wrong area, or struggle to find the right planning input.
A good sheet security design should match the planning process.
Users should see the sheets they need, at the right level, in the right version, with the right edit access.
How Access-Rule Security Works in Practice
In access-rule security, the setup usually follows a structured sequence.
First, users and groups are created. User profiles are assigned, and group membership is defined.
Second, permission sets are assigned. These determine what each role can do in the system.
Third, access rules are created. These define which intersections a user or group can view or edit.
Fourth, versions are configured. This determines which user types can access, edit, or view each planning version.
Fifth, levels are configured. This controls level visibility by version and planning process.
Finally, sheets and accounts are configured. This includes read-only behavior, salary detail restrictions, cube restrictions, and other sheet-level controls.
The final access behavior comes from all of these layers working together.
This is why security testing is important before go-live.
A user may appear to have the right access on paper but still be blocked by version settings, sheet settings, account settings, or access rules.
Default Security in New Adaptive Planning Instances
New Adaptive Planning instances usually start with default security components such as an admin user, a full-access permission set, level owner structures, and initial access rules.
These defaults give administrators a starting point and help prevent accidental lockouts.
A practical best practice is to protect the core admin access structure.
Do not casually delete or modify the main admin permission set or admin access rule without understanding the impact.
At least one trusted admin role should always retain full access to manage the environment.
Common Security Patterns
Most Adaptive Planning deployments use a few common security patterns.
The first is quick level access for department managers or cost center owners.
In this setup, the user is created, assigned the right permission set, added to the appropriate planning group, and assigned owned levels. The user can then work with the relevant data for their area.
The second is basic view access for executives, HR, operations, or leadership users.
These users may need to view reports, dashboards, or selected sheets without editing the plan. They usually need a view-only permission set and access rules that allow them to see the right levels, versions, and reports.
The third is planner edit access.
FP&A analysts and business planners may need edit access to planning versions, input sheets, and selected accounts. They may also need restrictions that prevent them from editing actuals or viewing salary detail unless approved.
These patterns should be documented so new users can be added consistently.
Controlling Access to Actuals
Actuals require stricter protection than plan versions.
Only specific users should be able to edit actuals.
In most environments, actuals should be loaded through controlled integrations or admin-managed processes. Users should not update approved historical data unless they have a clearly defined reason and permission.
There are two common approaches.
One approach is to create a restricted permission set with editable sheet access and privileged actuals access, then assign it only to approved users.
Another approach is to allow only administrators to edit leaf-level actuals.
The right approach depends on the operating model, but the principle is the same.
Actuals should be protected.
No one should accidentally change historical numbers that are used for reporting, forecasting, and variance analysis.
Refining Access for Sensitive Data
Some areas require additional control.
Compensation data, bonus pools, executive forecasts, confidential accounts, acquisition scenarios, and sensitive workforce plans should not be visible to all planners.
Adaptive Planning provides multiple ways to refine access.
Salary detail settings help protect compensation information.
Data privacy settings help prevent unauthorized cross-level references.
Cube restrictions can block sensitive intersections.
Read-only accounts can keep data visible while preventing edits.
Sheet visibility can limit which users can open certain planning areas.
In real implementations, these controls are often used together to protect HR data, workforce cost models, bonus assumptions, confidential headcount plans, and sensitive financial metrics.
Level-Based Security: Simple but More Rigid
Level-based security can be a good fit when the organization has a simple planning structure.
It works well when each planner owns a clear part of the hierarchy, reporting lines match access lines, and users do not need cross-functional planning access.
The model is easier to explain because users see the levels they own.
However, level-based security becomes limiting when the planning process requires more complex controls.
For example, if users need access by product, project, region, account group, or custom dimension intersection, access-rule security is usually better.
The main limitation is that level-based security cannot control custom dimension intersections in the same way access rules can.
That is why many growing organizations eventually move to access-rule security.
Why Security Design Should Happen Early
Security should not be designed at the end of implementation.
It affects model structure, sheet design, account setup, version strategy, workforce planning, reporting, and user testing.
If security is handled too late, teams often discover problems during UAT.
A planner cannot see the right level. A manager can view salary detail. A report shows data the user should not access. A sheet works for admins but not for business users. Actuals are editable by too many people. A dashboard exposes a sensitive version.
These issues are avoidable.
Security should be part of the model design from the beginning.
Common Security Mistakes
Common mistakes include giving too many users admin-level access, relying only on level ownership when access rules are needed, failing to restrict actuals, exposing salary detail too broadly, not testing access by role, creating overlapping access rules without documentation, forgetting version-level restrictions, and using sheets to expose data that should be handled through reports.
Another common mistake is designing security around individuals instead of roles.
Role-based security is easier to maintain. If access is assigned person by person, the model becomes difficult to govern as teams change.
A strong security model should be role-based, documented, tested, and reviewed regularly.
What Good Security Looks Like
A strong Adaptive Planning security model has clear signs.
Users can access only the levels, versions, accounts, sheets, and reports they need.
Sensitive data is protected.
Actuals are locked down.
Salary detail is visible only to approved users.
Planning versions are editable only during the correct stage of the cycle.
Reports and dashboards respect access controls.
Security is role-based, documented, and easy to maintain.
Admins can explain why each user has access and how that access is controlled.
This creates confidence for finance, leadership, HR, and system owners.
How EPM Logic Helps
EPM Logic helps finance teams design Workday Adaptive Planning security frameworks that match how their teams actually work.
We review roles, permissions, levels, access rules, versions, account settings, sheet settings, salary detail requirements, and actuals controls.
Our goal is to create security that is protected, practical, and easy to maintain.
A good security model should not slow down planning.
It should make planning safer, cleaner, and more predictable.
Final Thoughts
Security in Workday Adaptive Planning is not just an administrator responsibility.
It shapes the entire planning workflow.
Good security ensures planners see the right data, sensitive accounts stay protected, actuals remain accurate, budgets and forecasts are controlled, version governance is clean, and audit requirements are supported.
Poor security leads to confusion, broken sheets, accidental exposure, and loss of trust.
The concept is simple: decide who can see what, who can edit what, and how each planning layer should expose data.
The execution requires discipline.
When permissions, access rules, levels, versions, accounts, and sheets are designed together, Adaptive Planning becomes easier to govern and safer to use.
Security becomes cleaner.
Planning becomes easier.
Finance gains confidence that data is both accessible and protected.
