Security in Adaptive Planning looks 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 — levels, versions, accounts, sheets, permissions, and rules — works together to protect your planning data.

When teams understand how these layers fit, the system becomes easier to govern. Finance stays in control. Admins avoid accidental exposure of confidential data. And users only see the parts of the model that matter to their role.

Adaptive uses two security structures. You choose one based on how your organization manages access.

Level-Based Security vs Access-Rule Security

Adaptive gives you two ways to secure data.

Level-Based Security

Users can see only the levels they own.
This is simple, clean, and works well for organizations with straightforward reporting lines. Most FP&A teams start with this model because it mirrors their cost center hierarchy.

Access-Rules Security

You define rules that control who can view or edit specific intersections of data — levels, accounts, and custom dimensions.
This is more flexible and works better when you need granular control across departments or multiple planning dimensions.

Most mature Adaptive environments eventually move to access rules because it gives administrators more control and reduces manual ownership updates.

The Security Layers That Work Together

No matter which structure you choose, security is not a single switch. It’s a stack. Each layer reinforces the next.

Here’s how the system protects your data:

Credentials

Users sign in with an ID and password (or SSO).
This is the foundation.

Permissions

Permissions define where a user can go — sheets, reports, dashboards, modeling, administration.

Access Rules

Rules define what a user can see or edit.
They secure intersections like:

• Level + Account
• Level + Custom Dimension
• Territory + Product
  This is where most of the complexity lives.

Level Settings

Levels can be visible or hidden per version.
This helps control what users see for each planning cycle.

Version Settings

Versions can be hidden, locked, or editable depending on the user type.
This is essential for locking actuals and closing budgets.

Account Settings

Two key flags matter:

• Data Privacy: Controls which level’s data a user can reference.
• Salary Detail: Protects compensation detail for approved users only.

Sheet Settings

Sheets define the final guardrails:

• Mark as read-only
• Hide from sub-levels
• Restrict cube intersections
• Hide salary detail sheets

This combination ensures sensitive data stays where it belongs.

How Access-Rule Security Works in Practice

Most organizations use access rules when they need flexibility.
The process looks like this:

1. Create users and groups
   You set up user profiles and group memberships.
2. Assign permissions
   Each permission set controls navigation and capabilities.
3. Create access rules
   You define which intersections a user or group can view or edit.
4. Configure versions
   You decide which user types can access each version.
5. Configure levels
   You make levels visible per version.
6. Configure sheets and accounts
   You set read-only rules, salary detail flags, and cube restrictions.

Rules, permissions, levels, and versions all combine to deliver the final access behavior.

In real projects, most issues come from misalignment between these layers. A user might have access to a level but not the version, or access to a version but not the account. Understanding this layering avoids confusion during go-live.

The Default Security Setup in New Adaptive Instances

Every new Adaptive instance starts with:

• An admin user
• A Full Seat permission set
• A Level Owners group
• Two default access rules

These defaults protect the system from accidental lock-outs and give you a starting point to build security without breaking anything.

Best practice:
Never delete the Full Seat permission set or the admin access rule.

Giving Users the Right Access

There are three common security patterns in real deployments.

1. Quick Level Access

For cost center owners or department managers:

• Add user
• Assign permission set
• Add to Level Owners group
• Assign owned levels

They automatically get edit access to all data for their levels.

2. Basic View Access

For executives, HR, or operations:

• Add user
• Assign view-only permission set
• Create Full View access rules
• Make levels visible in versions
• Add levels to assigned sheets

They can see everything they need without editing.

3. Edit Access to Plan Versions

For planners and analysts:

• Assign Editable Sheet Access
• Add edit rules
• Grant full access to plan versions
• (Optional) Exclude salary detail sheets

This gives them the ability to plan but not change actuals.

Controlling Access to Actuals

Actuals require stricter protection.
Only certain users should edit them.

Two ways to manage this:

Restricted Permission Set

Create a permission set with:

• Editable Sheet Access
• Privileged Actuals Access

Assign to privileged users only.

Admin-Only Actuals

Make only the admin permission set able to edit leaf-level actuals.

These controls ensure no one updates approved historical numbers by mistake.

Refining Access for Sensitive Data

There are a few tools for controlling high-risk areas like compensation or confidential accounts.

• Salary Detail: Restricts access to modeled sheets or accounts with compensation data.
• Data Privacy: Controls how formulas reference values from other levels.
• Cube Restrictions: Blocks entire intersections of data in cube sheets.
• Read-Only Accounts: Prevents edits while keeping data visible.

In real implementations, these settings are used to protect HR data, workforce cost models, bonus pools, and sensitive metrics.

Level-Based Security: Simpler but More Rigid

Some teams prefer level-based security because it mirrors the organization. It works well when:

• Each planner owns a clear part of the hierarchy
• Reporting lines match access lines
• No cross-functional planning is needed

You still use the same layers — permissions, versions, accounts, sheets — but users only see the levels they own.

The biggest limitation:
You cannot secure custom dimension intersections without access rules.

Why Security Matters in Adaptive

Security is not just an admin 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
• Audit requirements are met

Poor security leads to confusion, broken sheets, and accidental data exposure.

For finance and operations teams, a well-designed security model makes planning smoother and more predictable.

How We Help at EPMLogic

We design security frameworks that fit how your teams work — not the other way around.
We map roles, permissions, levels, rules, and version controls so your system stays consistent, protected, and easy to manage.

Security becomes cleaner.
Planning becomes easier.
Teams get confidence that data is both accessible and protected.