As a business operations manager on the Anaplan on Anaplan (AoA) team—an internal team, focused on bringing Connected Planning to life within Anaplan—I help to oversee our internal Anaplan model ecosystem and assist in the solutioning and development of Anaplan models across all of our functional business groups.
As Anaplan's largest customer, one of the numerous requirements we must address is user access and security. Utilizing Anaplan's user roles functionality typically gets the job done for granting users access to specific models. Occasionally, we must go one step further and leverage Anaplan's selective access feature. Roles and selective access are powerful tools and address our needs nearly all of the time. However, as we scale our own use of Anaplan, we have begun to encounter the need to provision user's access to lists based on multiple criteria, rather than just a single condition.
In Real Life
A real-life user provisioning challenge we’ve encountered is in our headcount planning model. As this model provides real-time reporting on our employees, there are inherent sensitivities and considerations around who can see information for specific employees—taking into consideration visibility to things like compensation and personally identifiable information (PII). We have multiple use cases built out within the model, including recruiting capacity and analysis, attrition reporting, hiring reporting, etc., and the access to specific employee data depends on the end user of the model.
Sample employee roster: Joey manages Usain, Eluid, and Meb; Americas Geo; HR Cost Center.
In this example model, we have our complete employee roster included. If an HR business partner accesses the model, we want them to see only employees that are tagged to the functional area they support (e.g. finance, sales). Additionally, if a business manager goes into the model, they should only see information for employees where they are the manager, or employees downstream on their management chain.
But wait! If the HR business partner is in Europe, they shouldn’t be able to see PII fields for their employees. Do you see how this could get complicated quickly? Additionally, some dashboards that contain non-sensitive employee information are perfectly fine to open up broadly to all users, while others contain sensitive data we need to provision.
So, how do we handle this? We can’t provision access by roles because all of the aforementioned users need access to the same modules/dashboards as it relates to the employees they manage. Additionally, no single user should be able to see all data for all employees. Selective access could be considered as a solution, but given the levels of complexity and multiple logical drivers—as well as the requirement to not hide reporting of non-sensitive data for employees—that option also has limitations.
Enter Dynamic Cell Access (DCA). Since DCA allows us to base read/write access off of formulae logic, it offers us the ability to layer on multiple levels of logic ahead of deciding whether or not someone should be able to read or write on a particular item in a list. It’s dynamic (who would have thought with that name?), which means it adjusts live as data within the model changes. Additionally, it offers us the flexibility to apply the provisioning logic to the exact modules we want to, rather than blanket provision users across the model.
DCA In Action
The following is a high-level example of how to leverage the power of DCA:
Load employee roster data into Anaplan, ensuring the data contains the employee email—the same email that is used to log in to Anaplan. This allows for the mapping of Anaplan users to the employee roster.
Set up a System module with the ‘applies-to’ list of the user list. User meta-data staging module: Rows represent model users (Joey, in this example) and the line items represent meta-data off of the roster module.
Within this module, we can join the employee roster data and the user list to map the employee’s meta-data to their Anaplan user profile (e.g. cost center, location, management chain, etc.)
Using a series of Boolean line items, we can write whatever logic we want to base our DCA on. In our example, this could include: Is HR business partner? Is Euro? Basically, this is a staging module for all of the employee meta-data we want to leverage to create our DCA drivers.
Set up a second System module with the ‘applies-to’ list of whatever list you want to apply DCA against, as well as the user list. In our case, this would also be our employee roster list.
Create a series of Boolean line items, testing different attributes of the User System module we just set up against the meta-data of the employees. An example would be (Employee Cost Center = User’s Cost Center). DCA logic module for the employee roster list (rows in this module): Line items represent the logic used to determine whether the user (Joey— in the page selector) can see the employee. The key here is to consolidate all of your logic into a single “Master” line item, which is on the far right.
Daisy chain your conditions together as desired, with the end result being a master Boolean line item, which is the driver for whether or not a particular user has read or write access to a particular item within the list. In this dashboard you can see that the information is masked for those employees that did not meet all of the criteria identified in the master DCA line item.
Select which modules you’d like to apply DCA to. The nice thing about DCA is you can go down to the line item level to map the master Boolean driver against.
The incredible power of the process described above is not only the complete control over and ability to customize your user provisioning, but also that as new roster data is loaded into Anaplan, the DCA automatically adjusts itself to account for changes. So, if someone changed cost centers or a manager on an employee changed, the formulas that we set up above would be referencing the new employee meta-data, and would automatically adjust the DCA drivers, allowing for a much more hands-off, sustainable approach to user provisioning.
Another inadvertent benefit we discovered with using this methodology is that Anaplan treats cells that are blank as a result of DCA drivers as being blank for filtering purposes. So, if you want to set up a dashboard that auto-filtered employees for the end user based on the logic above, you just have to add a line item hardcoded to contain values for every list item, and then filter that line item for not-blanks on your dashboards. Then you have a dynamic filter based on the user that is viewing the model…pretty slick!
Take this one step further and filter for not-blanks on a line item that will always contain data for an employee, and you get completely custom reporting based on which end user is viewing the dashboards.
... View more
@Guido.kaandorp , that's a great point. there are many ways to tag the modules, certainly if the module names are important for your user experience you could organize using DISCO using the data tags functionality, notes etc. something that only WSAs can see.
... View more
As winter is now behind us and the annual process of “spring cleaning” begins, I find that it is a good reminder to not only clean and organize my house, but also to clean another area that most likely needs some organization: my Anaplan models. The beauty of Anaplan’s platform is that it gives the model builder an extremely powerful tool that can be customized exactly the way the model builder would like. Oftentimes, I am either so anxious to produce the result I want (or under such a tight deadline), that I forgo best practices and “clean” model building for quick delivery instead. Similar to how I may not dust in every corner or clean every nook during the winter months, I find myself with “dirty” Anaplan models that could use a nice deep cleaning and organizing.
Thankfully, Anaplan has a guide on how a “clean” model should look and function. These practices enhance the sustainability and auditability of the model, while simultaneously increasing the model’s performance. It’s called the D.I.S.C.O. methodology . This handy acronym stands for Data, Input, System, Calculation, and Output. Each word represents a certain function (or responsibility) that each module with an Anaplan model should perform. The D.I.S.C.O. methodology provides an overview of how data should flow between modules and how your model map should look.
The general data flow between the D.I.S.C.O. modules.
At a high level the individual types of modules perform the following functions:
Data modules: Serve as targets for any data inbound from sources other than the model. These could be data loads from a data hub model, loads from other models or manual or automated loads from another system like your CRM or ERP.
Input modules: These modules collect information input from the end users of the model, they could drive mappings, calculations, filters, etc.
System modules: System modules hold fairly static data points, mappings that are defined by the Workspace Administrators, or standard calculations that rarely (if ever) change. A good example is a time management module which includes functions that do not change between modules, such as PERIOD(START()). By storing calculations like this in a single module, Anaplan only needs to calculate the function once and can reference it wherever it is needed.
Calculation modules: These are the heart of the Anaplan model. They serve as the meeting point of Data, Input, and System modules, where it all comes together to produce the desired outcomes. The heavy lifting of formulas and functions is performed in these modules.
Output modules: Last, but certainly not least, the Output modules take information from the Data, Input, System, and Calculation modules to produce reporting for dashboards and other models to reference in import actions. Output modules should usually only have incoming streams from other modules, as they are the final result of all of the other modules’ hard work.
While the D.I.S.C.O. methodology is typically referenced and considered when starting a model build, it’s no less applicable or important in the later stages of a model’s lifecycle. Even the best-made models will collect dust and dirt over time, in the form of redundant calculations and convoluted data flows.
As I clean my models this spring, I‘d like to share a few quick tips I will be using in the process:
Develop a system to tag each module to a specific purpose within D.I.S.C.O.
If I haven’t already, I’ll develop a system to tag each module to a specific purpose within D.I.S.C.O. It’s user choice here—you could use Anaplan’s notes feature, data tags, module names, or functional areas. I’ve found that organizing modules into D.I.S.C.O. functional areas helps me keep them organized. I also prefix my modules with DAT/INP/SYS/CAL/OUT and number them to make finding and referencing them much easier.
If you can’t make sense of it in ~15 seconds, your model is most likely not adhering to the D.I.S.C.O. methodology
Once you’ve organized your modules, take a look at your model map. If you can’t make sense of it in ~15 seconds, your model is most likely not adhering to the D.I.S.C.O. methodology, and likely has multiple modules performing the same calculations, deprecated modules, or the same data living in multiple places. A few questions I ask myself are:
Do my modules flow logically from left to right (e.g. Data/Input/System on the left, Calc in the middle, and Output to the right?) Are there modules to the right of my Output modules that are Data, Input, System, Calculation?
Do I have modules referencing output modules?
Are there arrows going both ways between modules?
Can I pick a line item on an Output module and easily follow it all the way back to the beginning of the calculation and data source? As the above screenshot illustrates with Data in red, System in Yellow, Calculation in Purple, Input in Green, and Output in Orange.
The easiest way to begin is to address any Output modules that are referenced by other modules
Next, I’ll reduce module size and unused cells. The easiest way to begin is to address any Output modules that are referenced by other modules. Once I clean those references up and move the calculations to a Calculation module, any Output modules that are not used on a dashboard and Calculation modules that do not have any modules using them as references are quick wins to delete and reduce my model’s size.
Redundant formulas are also quick model size and performance wins
Redundant formulas are also quick model size and performance wins to consolidate to a single calculation module or move to a system module. An example would be to search for PERIOD() functions. If you are calculating the time period on multiple modules, that can be done on a single line item in a time system module and then referenced as needed by each module that needs the period. Not only does this remove the redundant line items and reduce model size, but it also increases the model’s performance, as it now only needs to calculate the time period once.
Model performance can be increased by removing line item summaries
Since Calculation modules are not intended to be displayed to end users, model performance can be increased by removing line item summaries on Calculation modules that are not needed downstream in Output modules.
More About Model Building:
Best Practices for Module Design
PLANS – This is How We Model
With spring in full bloom, it is a great reminder to not only clean up your house/apartment/flat but also your Anaplan models. Of course, these tips should not be used to “clean” your models once a year, but rather a guide for ongoing model building, and constantly reviewed on a regular basis. Hopefully, you found something useful in this article.
Happy Model Building!
Joey Morisette is a Business Operations Manager on Anaplan’s internal Center of Excellence team known as “Anaplan on Anaplan.” Previously, Joey worked at an Anaplan customer where he led the development and implementation of the Anaplan platform.
... View more