Author: Artem Shchaulov is a Senior Anaplan Consultant and Certified Master Anaplanner with 8+ years' experience implementing global EPM solutions.
In my first article, we established why access management breaks at enterprise scale and why a dedicated User Access Management (UAM) model is the only architecture that works long term.
This article focuses on the practical side: how to build the UAM model and make it scale reliably across many models, hierarchies, and users.
The key idea is simple: access logic must be centralized, explicit, and automated — but built in a way that respects Anaplan’s performance and constraints.
The role of the UAM model in the landscape
The UAM model is not just another spoke model. It is a governance model.
Its responsibilities are:
- Store all users and identity metadata
- Mirror all hierarchies used for selective access
- Define access logic (read / write / none)
- Enforce responsibility boundaries
- Prepare export views for CloudWorks
- Act as the single source of truth for access
Because the number of users and qualified administrators is relatively small, the UAM model does not require ALM in most cases. Keeping it as a single productive model reduces complexity and operational overhead.
Required inputs Into the UAM model
The UAM model typically consumes data from three sources.
From SCIM / Workspaces:
- User existence
- Activation / deactivation
- Workspace membership
SCIM ensures users exist — nothing more.
From Identity System (via API)
Additional metadata is pushed via API, for example:
- Department
- Region
- Functional responsibility
- Cost center
- Employment status
- Organizational grouping
- Any custom attributes relevant for planning
This metadata is critical, because access should be derived from business rules, not from static user lists.
From the Data Hub
- All selective-access hierarchies
- List items used in spoke models
- Stable identifiers for mapping access
The UAM model must always reflect the same structural reality as the spoke models.
Building access modules per spoke model
Access is managed per spoke model, not globally.
For each spoke model:
- Identify every list that uses selective access
- Build one access module per list
Typical dimensions:
- Users
- Selective-access list (e.g., products, geographies)
Typical line items:
- Select access (write/read/none list) with Color formatting
- Access from the higher level (write/read/none list)
- Write (list item)
- Read (list item)
- None (list item)
- Color formatting to identify that this level already has Write or Read access
Access seniority logic
Access must always resolve to exactly one state:
- Write overrides Read from the higher level
- Read overrides None the higher level
- None must be explicit
Explicit “none” is essential. Without it, access removals will not propagate correctly.
Why “none” must be explicitly managed
A common mistake in large implementations is assuming that removing Read or Write automatically removes access. It does not.
If “none” is not pushed:
- Users may retain access they should no longer have
- Selective access becomes impossible to revoke reliably
The UAM model must therefore export write, read, and none states explicitly.
CloudWorks configuration
CloudWorks is used to push access into spoke models. Usually during the night with 5-10 min intervals for different models.
Important constraints:
- CloudWorks cannot create users
- CloudWorks can assign roles
- CloudWorks can assign selective access
- CloudWorks can push access text data to access modules
- CloudWorks can run at scale on a schedule
For each spoke model:
- Create CloudWorks imports for roles
- Create CloudWorks imports for selective access
- Point them to saved views from the UAM model
Scheduling and orchestration
Order matters. A stable nightly sequence is:
- Data Hub refresh (hierarchies)
- Spoke model refresh (list updates)
- UAM → Spoke access push (CloudWorks)
This prevents assigning access to list items that do not yet exist.
Running access updates during the night is usually well accepted by users and avoids performance impact during working hours.
Full load vs delta load
Initial setup requires a full access load:
- All users
- All list items
- All access states
At enterprise scale, if selective access used for Product level multiply with thousands of users = big amount of data load. It can take 30–40 minutes.
After initialization, the system could be switched to delta loads for same selective access lists:
- Only changed access is pushed
- Previous snapshots are stored
- Unchanged intersections are ignored
Delta logic is the difference between a working system and one that becomes unmaintainable.
User-facing transparency in spoke models
The UAM model enables something that standard Anaplan security does not: self-diagnostics. For that you need to push some text access information to the modules with a users dimension. That will allow users to see their access.
As a result, in spoke models, users can:
- See their own access
- Understand why something is hidden
- Compare their access with a colleague
- Request “same access as X” with clarity
This alone removes a large percentage of access-related support requests.
Qualified users and governance rules
Access changes should not be open to everyone. It should only be a small group of qualified users that already participate in testing and are trusted by the teams.
A small group of qualified users:
- Understands the business hierarchy
- Knows the planning processes
- Is trusted to manage access
Safeguards for qualified users:
- Qualified users can grant access only within their own responsibility (Region, segments or anything else)
- They cannot modify their own access
- Admins are removed from daily access operations
This model scales because decision-making sits with people who understand the data, not with central administrators. One night waiting time is easy to sell to the users.
User interaction and access representation
All interaction with access logic should happen through UX pages, not directly in modules. This keeps the UAM model usable, auditable, and safe, while allowing qualified users to work efficiently.
In practice, this results in three types of pages, each serving a different purpose.
Main access management page (UAM Model)
This page is typically available only to qualified users and is built per spoke model. Its purpose is to provide a complete, compact overview of access for a selected user.
A well-designed access page usually includes:
- The name of the spoke model the access applies to
- The selected user, including name and role information
- A compact summary of the user’s current access at the top
- A set of tables below, one per selective-access list used in the spoke model
Each table should be designed for clarity and density:
- Access is maintained through a single dropdown per item (Write / Read / None)
- The current effective access state is highlighted using color coding
- No additional “final access” columns are required, as visual cues communicate the result clearly
The goal is to make all relevant access visible on one page, without forcing users to navigate across multiple dashboards.
Access copy page (UAM Model)
A separate page should support one of the most common enterprise access scenarios:
“Give this user the same access as another user.”
This page allows qualified users to:
- Select a source user and a target user
- Copy access either fully or selectively
- Immediately see whether the two users already have identical access
Visual indicators should clearly show:
- Identical access
- Partial differences
- Conflicts requiring review
This functionality alone can eliminate a large portion of access requests and significantly reduce manual effort.
Access visibility page in spoke models
In addition to the UAM model itself, each spoke model should expose a read-only access visibility section for end users.
This section is typically placed:
- On the landing page, or
- On the first functional page of the model
Its purpose is not to manage access, but to make access transparent.
It allows users to:
- See their own access across relevant hierarchies
- Understand why certain data is visible or hidden
- Compare their access with colleagues
- Articulate access requests precisely
- Onboard faster with fewer questions
This simple addition dramatically reduces confusion, support tickets, and incorrect access requests.
Summary
A scalable UAM model is not about automation alone. It is about explicit logic, responsibility boundaries, and disciplined execution. When built correctly, the UAM model:
- Scales to thousands of users
- Handles millions of access intersections
- Remains auditable
- Remains understandable
- And remains trusted
Questions? Leave a comment!
