Dynamic Cell Access Tips and Tricks

Dynamic Cell Access (DCA) controls the access levels for line items within modules. It is simple to implement and provides modelers with a flexible way of controlling user inputs. Here are a few tips and tricks to help you implement DCA effectively.

Access control modules

Any line item can be controlled by any other applicable Boolean line item. To avoid confusion over which line item(s) to use, it is recommended that you add a separate functional area and create specific modules to hold the driver line items. These modules should be named appropriately (e.g. Access – Customers > Products, or Access – Time etc.). The advantage of this approach is the access driver can be used for multiple line items or modules, and the calculation logic is in one place. In most cases, you will probably want read and write access. Therefore, within each module it is recommended that you add two line items (Write? and Read?). If the logic is being set for Write?, then set the formulas for the Read? line item to NOT WRITE? (or vice-versa). It may be necessary to add multiple line items to use for different target line items, but start with this a default.

Start simple

You may not need to create a module that mirrors the dimensionality of the line item you wish to control. For example, if you have a line item dimensioned by customer, product, and time, and you wish to make actual months read-only, you can use an access module just dimensioned by time. Think about what dimension the control needs to apply to and create an access module accordingly.

What settings do I need?

There are three different states of access that can be applied: READ, WRITE, and INVISIBLE or hidden. There are two blueprint controls (read control and write control) and there are two states for a driver (TRUE or FALSE). The combination of these determines which state is applied to the line item. The following table illustrates the options:

    1. Only the read access driver is set:
        Read Access Driver
      Driver Status True False
      Target Line Item READ INVISIBLE
    2. Only the write access driver is set:
        Write Access Driver
      Driver Status True False
      Target Line Item WRITE INVISIBLE
    3. Both read access and write access drivers are set:
        Read Access Driver Write Access Driver
      Driver Status True False True False
      Target Line Item READ INVISIBLE WRITE Revert to Read*
      *When both access drivers are set, the write access driver takes precedence with write access granted if the status of the write access driver is true. If the status of the write access driver is false, the cell access is then taken from the read access driver status.

The settings can also be expressed in the following table:

TRUE Write Read Read
FALSE Write Invisible Invisible
NOT SET Write Invisible Write

Note: If you want to have read and write access, it is necessary to set both access drivers within the module blueprint. 


Think about how you want the totals to appear. When you create a Boolean line item, the default summary option is NONE. This means that if you used this access driver line item, any totals within the target would be invisible. In most cases, you will probably want the totals to be read-only, so setting the access driver line item summary to ANY will provide this setting. If you are using the Invisible setting to “hide” certain items and you do not want the end user to compute hidden values, then it is best to use the ALL setting for the access driver line item. This means that only if all values in the list are visible then the totals show; otherwise, the totals are hidden from view.

Labels (1)
Version history
Last update:
‎09-29-2020 08:57 AM
Updated by:
The content in this article has not been evaluated for all Anaplan implementations and may not be recommended for your specific situation.
Please consult your internal administrators prior to applying any of the ideas or steps in this article.



With ALM, DCA works in Dev, but will not allow you to sync the model to Production. The problem was that the boolean line item used for DCA had too many conditions and would only work if it had one argument. Is there any way to fix this issue?





Hi - There is a known issue which means the DCA line item needs to be created in one revision, the models sync'd and then applying the driver done in another revision, but could you log this with support so that our product team can investigate fully




To be fair, ALM and DCA also sometimes does not work if you change the formula in the DCA line item. This is particularly annoying when the DCA line item is attached to a large number of line items in the model. What you basically have to do then is to remove all DCA from the model using the ‘Line items’ tab under ‘Modules’, synch the model, then add the DCA again, and then re-synch.

This does not happen every time, so I have no idea what type of formula changes that triggers it. But it's really annoying and a big time sink. 




Indeed when you use DCA, you need to create first the line-item in DEV push it into PROD using ALM and only after that adding in DEV the line item as DCA in different modules. 

this is how it works...




After some testing, it appears the issue has been solved and you can now create a driver and apply DCA within the same Revision Tag. 


Would be great to get some official confirmation, could only found this in recent releases: https://community.anaplan.com/t5/Releases/Upcoming-Maintenance-February-22-2020/ba-p/60434




Today I made some tests and it seems that this issue is solved.

If the boolean line-items are created and used as DCA flags can be pushed and sync together in the same revision tag into PROD model. 

It seems that it is not needed anymore to have this done in 2 separate revision tags. 


Hi, reading through this article wouldn't the last caption be ALL instead of any in the TOTALS part :

"If you are using the Invisible setting to “hide” certain items and you do not want the end user to compute hidden values, then it is best to use the ANY setting for the access driver line item. This means that only if all values in the list are visible then the totals show; otherwise, the totals are hidden from view..."

Hi @david.savarin - I agree. You are right - it should be ALL not ANY.
Obviously it is a typo, as the explanation is correct 😀

Thanks @david.savarin 

I'll get that changed


Is there any article/post on how DCA behaves within a Composite Hierarchy?


Use Case: I have a 7 level Org hierarchy where user will control the Write access at L2. Tried referencing this down to a line item dimensioned by Org L6 using lookup which is then used this as the Write access driver and this worked. But, when I try doing the same thing using a line item dimensioned by any level above Org L6, the access control doesn't work and the line item remains read only even if the parent node is TRUE for write access driver line item. Is this expected as we were thinking on the lines of "if it works at the immediate parent it would work at the higher levels of hierarchy as well"?


This is not a requirement or an issue, but came across this while experimenting different scenarios, so just wanted to check as I couldn't find much else on the community related to DCA.





Have you looked at the summary options for the driver module - If you use the ANY or ALL summary method this will populate the composite list parent in the driver module

You can then reference that same line item in the higher level target modules

this is shown in the following - The summary settings are ANY in the L3 driver module

2020-11-24_13-44-42.jpgYou can see the L2 driver is used in the following module2020-11-24_13-46-56.jpg


I hope that helps


The scenario I was trying to explain above has the Target module at a lower level of the hierarchy (L7) and Driver module at a higher level (L2). If I keep the Driver line item at L6, it works. But, if this is at any level higher than that, then it doesn't. The summary being used for L2/L6 driver line item is All, but I don't think it matters (All or Any) if the target module is at a lower level. 


It still works for me if I reference the L2 Driver in another line item in the Driver module dimensioned by L6/L7. But, just wanted to validate if I'm thinking about this rightly.



Great article breaking down how to adopt DCA utilizing best practices.