Author: Artem Shchaulov is a Senior Anaplan Consultant and Solution Architect with 8+ years' experience implementing global EPM solutions.
In my experience, User Access Management (UAM) inside Anaplan works perfectly as long as the model footprint is small. The built-in UI allows administrators to add users, assign roles, and set selective access on lists. That approach is fine for a few dozen people, maybe even a few hundred.
But when a company expands across functions, regions, and planning processes, it becomes more complicated. With thousands of users, dozens of selective-access hierarchies, and millions of potential user–item intersections, it’s best to explore different methods.
Administrators can have challenges keeping up, business users cannot see their own access, identity systems cannot translate structure into selective access, and onboarding/offboarding becomes a time-consuming, error-prone process.
This inevitably pushes enterprises to look for a scalable, governed approach to access. And when you examine all available options closely, it becomes clear why so many deployments get stuck — and what is needed to build something stable.
Four ways to manage access in Anaplan — and my recommendation for the most scalable option
Before discussing architecture, it’s important to lay out all options that enterprises have today. Each option has strengths and weaknesses.
We will go through them in order of increasing sophistication.
Option 1: Manual access
This is the default; you add users manually, give them roles manually, and assign selective access manually.
It works best when:
- you have <100 users
- you have only a few lists with selective access, if any
- each model is operated by a small team
It becomes challenging when:
- there are thousands of users
- there are dozens of selective access lists
- lists contain hundreds of thousands of items
- you have a dozens of onboarding request daily just to your architect
- users need to compare their access with colleagues
Manual access is simply not an enterprise-grade solution.
Option 2: SCIM (Identity System → Anaplan Workspaces)
Most large companies use an identity management system such as Okta, Azure AD/Entra, Ping, SailPoint, or OneLogin. These platforms rely on SCIM to create and deactivate users in Anaplan automatically.
SCIM is excellent at:
- provisioning new users
- de-provisioning users
- keeping identity data consistent across systems
But SCIM cannot:
- assign model roles
- assign selective access
- interpret hierarchy logic
- enforce read/write/none
- limit what permissions a user can grant
- understand business responsibility boundaries
SCIM solves the identity lifecycle — not the permission lifecycle.
Option 3: Custom API solutions
Another option is to automate access purely with the Anaplan API. API scripts can grant model roles, assign selective access, and even push updates on a schedule.
But pure API solutions may not be the best solution because:
- every model requires its own custom script
- logic becomes fragmented across environments
- scripts cannot enforce governance rules
- there is no visibility for business users
- there is no concept of qualified users or responsibility boundaries
- APIs know nothing about business hierarchy or ownership
- maintenance cost grows with every model and hierarchy added
API solves the mechanical part, but not the business logic or governance.
Option 4: UAM Model (SCIM + API + Anaplan logic combined)
The fourth option — and the one that scales best — is to introduce a dedicated User Access Management (UAM) model into the Anaplan landscape.
This UAM model becomes the centralized access brain of the entire ecosystem.
It takes:
- SCIM’s ability to create and remove users
- API’s ability to pass identity metadata (emails, names, department, region, status, etc.)
- CloudWorks’ ability to assign roles, selective access and run nightly
- Anaplan’s build in logic, responsibility boundaries, transparency and scalability
…and unifies them into one controlled, scalable process.
The UAM model is where access is defined, validated, governed, and distributed.
It replaces manual chaos, SCIM limitations, and API fragmentation with a clear, stable, controlled flow.
Everyone starts to trust it.
My recommendation: SCIM + API + UAM + CloudWorks
Once you evaluate all four access methods, the architecture practically designs itself.
Here is the flow that works in every large deployment:
Identity System -> SCIM -> Anaplan Workspaces
SCIM automatically creates users in all necessary workspaces. They appear as empty shells — active users with no roles and no selective access.
This keeps identity lifecycle clean and consistent.
Identity System -> API -> UAM Model
API is used to push additional identity metadata into the UAM model. This metadata includes:
- Department
- Region
- functional responsibility
- cost center
- employment status
- organizational grouping
- any custom attributes needed for planning
This allows access logic to be tied to business rules, not to static user lists.
UAM Model -> CloudWorks -> Spoke models
This is where access is actually assigned.
CloudWorks cannot create users. But CloudWorks can:
- assign model roles
- assign selective access
- push changes at scale
- execute scheduled updates safely
This is why the chain works: SCIM creates users. CloudWorks changes users.
This separation prevents performance issues, avoids duplication, and stops uncontrolled user creation.
Why the UAM architecture works
When you combine SCIM, API, CloudWorks, and Anaplan logic inside a single UAM model, you solve every structural problem that appears at enterprise scale.
The UAM model enables:
- Centralized access logic: One model defines every rule, every hierarchy boundary, and every selective-access assignment.
- Ease of management: Only qualified users can change access, they cannot grant access outside their responsibility, they cannot modify their own access, and admins are removed from the daily loop.
- Business transparency: Every user can finally see what access they have; not in UAM, but in Spokes models. They can compare with a colleague and understand what’s missing and why.
- Cost allocation support: Since the model knows who has read and who has write access to which models, it becomes a natural place to allocate Anaplan license cost.
- Integration with org metadata: Access can be tied to departments, regions, cost centers, or any other structure.
- Scalability to millions of intersections: UAM can handle full loads and delta loads. I plan to write about this next!
Conclusion
At small scale, manual access is workable.
At medium scale, SCIM and API can help.
At enterprise scale, only UAM is sufficient.
The UAM model is the only architecture that creates a stable, governed, scalable access-management process across dozens of models and thousands of users. It unifies identity lifecycle, permission lifecycle, business hierarchy, transparency, and cost allocation into one model.
Questions? Leave a comment!
