Every Anaplan rollout reaches the same awkward moment. The model works, the numbers reconcile, and then someone asks: "How do we stop the regional planners overwriting last quarter's actuals?" or "Can we open input for Marketing but freeze Finance while they review?"
Roles and selective access answer the first half of that question. They cannot answer the second half, because they are static: they describe who a user is, not what state the plan is in right now. Dynamic Cell Access (DCA) is the feature that closes the gap, and it is the single most under-used control in most production models.
This tutorial walks through building DCA properly: when to reach for it, how to structure driver modules, how to drive locks from a planning calendar or a workflow status, and how to test it before it reaches planners.
DCA versus the alternatives
Three mechanisms control what a user can do with a cell. They stack, and the most restrictive one wins.
| Mechanism | Granularity | Driven by | Changes at runtime? |
|---|---|---|---|
| Role access (module/list level) | Module, list, action | User's role | No |
| Selective access | List items within a list | User-to-item assignment | Only by re-assigning users |
| Dynamic Cell Access | Individual cells | A Boolean line item you calculate | Yes — instantly |
The practical rule: use roles to decide which modules a person can see at all, selective access to decide which entities (cost centres, products, regions) they own, and DCA to decide what is editable right now given the calendar, the workflow state, the data itself, or the scenario being planned.
Reaching for DCA to do a role's job is a common mistake. If a whole module should be invisible to a user group, that is a role setting, not a Boolean.
The building blocks
DCA is applied per line item. Each line item can be pointed at two Boolean line items in a driver module:
- Read access driver — TRUE means the user can see the cell; FALSE blanks it out.
- Write access driver — TRUE means the cell is editable; FALSE renders it read-only (greyed).
The rule that trips up new builders: the driver module must be dimensioned by a subset of the dimensions of the target module, and the driver line item must be a Boolean with no time dimension unless the target has one. In practice that means the driver module can be less granular than the target, never more.
That subset rule is a gift, not a limitation. A single driver module dimensioned only by Cost Centre and Time can control fifty line items across a dozen modules. Resist the temptation to build a driver module for every input module; you will end up maintaining fifty copies of the same logic.
Build it: locking inputs by planning period and workflow status
Here is a worked example — an expense planning model where planners submit budgets by cost centre, and Finance opens and closes submission windows.
Step 1. Create the control module
Create SYS Planning Status by Cost Centre, dimensioned by Cost Centre and Time (Month). Line items:
Period Locked? Boolean Formula: 'SYS Time Settings'.Actuals Period?
Submission Status List (Submission Status) Input
Submitted? Boolean Formula: Submission Status = 'Submission Status'.Submitted
Approved? Boolean Formula: Submission Status = 'Submission Status'.Approved
Keeping the status as a list rather than a set of Booleans pays off later — statuses multiply, and a list is easier to extend than four correlated flags.
Step 2. Create the DCA driver module
Create DCA Expense Input, dimensioned by Cost Centre and Time. One line item to start:
Can Edit Expense? Boolean
Formula: NOT 'SYS Planning Status by Cost Centre'.Period Locked?
AND NOT 'SYS Planning Status by Cost Centre'.Submitted?
AND NOT 'SYS Planning Status by Cost Centre'.Approved?
Read the formula out loud: a planner can edit an expense cell when the period is not an actuals period, and the cost centre has not yet submitted, and it has not been approved. That is the whole business rule, in one place, testable on its own.
Step 3. Attach the driver to your input line items
Open the expense input module, select the input line items, and in the line item's Blueprint set Write Access Driver to DCA Expense Input.Can Edit Expense?. Leave the read driver empty unless you genuinely need to hide cells — hidden cells confuse planners far more than greyed ones.
Save and switch to a planner's view. Locked periods are grey; open periods take input. No page refresh, no re-publishing, no admin intervention.
Step 4. Add the role dimension without adding a role dimension
The usual next requirement is "Finance can still edit after submission." Do not build a second driver module. Add a Users-dimensioned override:
SYS User Override (dimension: Users)
Finance Override? Boolean Input, maintained by admins
DCA Expense Input (dimensions: Users, Cost Centre, Time)
Can Edit Expense? Boolean
Formula: 'SYS User Override'.Finance Override?
OR (NOT Period Locked? AND NOT Submitted? AND NOT Approved?)
Adding Users to the driver module is legitimate — Users is a dimension like any other, and the target module inherits it implicitly because DCA is evaluated per logged-in user. Watch the size, though: Users × Cost Centre × Time can grow quickly, and DCA drivers are calculated cells like any other.
Driving DCA from Anaplan Workflow
If you are already using Anaplan Workflow for approvals, do not rebuild the status logic. Land the workflow's task status back into the model — via the workflow's own model updates or an integration — into your SYS Planning Status module, and let DCA read from it exactly as above.
The pattern is worth stating plainly: Workflow owns the process state; DCA owns the consequence. Keeping those separate means you can change the approval chain without touching a single Boolean formula, and you can re-use the same DCA drivers for a model that has no workflow at all.
Performance notes
DCA drivers are ordinary calculated cells, so ordinary performance rules apply.
- Keep drivers coarse. A driver dimensioned by Cost Centre × Time is cheap. The same logic replicated at Cost Centre × Product × Employee × Time is not.
- Avoid formulas inside the driver that walk large lists. Compute the underlying flags in a systems module, then reference them.
- One driver, many consumers. Line items across different modules can all point at the same Boolean, provided the dimensionality subset rule holds.
- Do not drive DCA from a line item that itself depends on user input in the same module. Circular-feeling dependencies are legal but produce confusing recalculation behaviour for the planner.
Testing before planners see it
DCA bugs are silent — nobody files a ticket saying "I could edit something I shouldn't have." Build the test into your release process:
- Matrix test. List every user persona against every plan state (open, submitted, approved, locked period). Confirm the expected edit/read-only outcome for each. Ten minutes of this catches most defects.
- Test with a real non-admin login. Workspace administrators bypass selective access, so admin testing hides whole classes of bug. Use a genuine test user in each role.
- Check the import path. DCA blocks manual entry, but an import action run by an admin can still write into locked cells. If that matters, gate the action itself, not just the cells.
- Check formula-driven line items. DCA on a calculated line item is pointless; the calculation still runs. Lock the inputs that feed it.
- Promote through ALM. Driver modules and DCA settings are structural, so they move with a revision tag. The user-override list contents, if the list is a production list, do not — plan for that.
Common mistakes
- Hiding instead of greying. Read drivers that blank cells make totals look wrong to the person reading them. Grey is honest; blank is a support ticket.
- A driver module per input module. Duplicated logic drifts. Consolidate.
- Encoding roles in Booleans. If a rule never changes at runtime, it belongs in a role or selective access, not DCA.
- No visual explanation. A greyed cell with no reason is frustrating. Put the current status and the lock reason on the same UX page, next to the grid.
- Forgetting the actuals boundary. The most common real-world lock — "no editing in closed periods" — should come from your central time-settings module, not a hard-coded date.
Where to go next
Once the driver pattern is in place, DCA becomes the cheapest control in the model. Common extensions: opening a single re-forecast window for one region without touching anyone else, freezing a baseline scenario while leaving what-if versions editable, and making reference data read-only in the same module where planners enter overrides.
If you are retrofitting DCA into a model that has grown organically, the work is usually less about formulas and more about deciding who owns which state — and that is a conversation worth having before you write the first Boolean.
QuanticPlanning builds and hardens Anaplan models for planning teams that have outgrown spreadsheets and workarounds. If you need help designing access control, workflow, or the release process around it, get in touch.