Author: Luke Grady is a Certified Master Anaplanner and Solution Architect at Tru Consulting.
This article will cover ideas related to metadata within an Anaplan model. Metadata are lists and modules that model builders can create related to the model itself. These metadata provide information about models to stakeholders, facilitate navigating from App pages to models, and help visually distinguish different models in the ALM path to production.
When we have one app page with multiple source models, it's easy to miss the drop-down selector value and think you're in a different model than you really are. Creating a SYS Model Information to store information about the model itself can help to identify whether we're looking at the Dev, Test or Production model. This can be easily accomplished by creating a Models list in Anaplan. This list is structural, and maintained by the model builder. Example is below. Note the whimsical use of emojis in the model names.
Image: Sample models list
Of course, this list will be accompanied by a System Module. A key aspect of this module is the Boolean line item to denote the Production model which drives the Display String line item. The idea behind the Display String line item is that it can be published on app pages using dynamic text to visually cue a user that they are not in the production model. If we're in our production model we will display a blank text so there's no interruption or confusion for our users-they don't even have to know that DEV and TEST exist. This visual makes it really easy to see that we are not in Production, which is super useful for us as model builders or admins with access to multiple models.
Image: Sample SYS Models module
Another piece of the build is an Administration module where we as model administrators enter additional model metadata to identify the model itself.
In this module, we have a pick list where we select the model from the Models list above. We can also put in our Customer ID, Workspace ID and Model ID. This information serves two purposes: 1) it's useful information to display on an app page, makes it easier to get to the information (think about your IT department who is building your data integration and needs to know the model and workspace IDs but doesn't use Anaplan every day to know to go to the Help -> About menu to access this information), and 2) making custom links to the selected model. Read more below.
Image: Sample SYS Model Information module
One really cool use of the model, workspace ID and model ID metadata is during the annual roll forward process. I like to build app pages for users that contain instructions for what a model administrator needs to do to roll forward the model each year. The annual roll forward has a lot of steps, and some of them need to be performed in Dev, and others in your deployed models.
The model metadata allows us to both identify which model we're in, and also make clickable links that will take us to the place in the model we're referencing using the MAKELINK() function. Note: not available in Polaris at the time of this writing.
Now my model roll forward instruction page can have a clickable link to the Time pane and Revision tags in the model for DEV. And for example a link to the Users pane in Prod and Test if you need to direct users to this page to manage selective access or user roles. By referencing the model ID and workspace ID you can build links to the specific model. Example below.
Image: Sample SYS Links module
Conclusion
Managing and maintaining metadata about the model itself within the model is a powerful and useful tool that can ease access to information about the models we build as well as enhance functionality and usefulness of the tools. This brief article gives a mere taste of the possibilities that exist when we manage our metadata in an Anaplan model.
