Getting to know your model

Stacey_Gibbens
Stacey_Gibbens
edited July 2023 in Blog
StaceyG_blog.jpg

Author: Stacey Gibbens is a Certified Master Anaplanner and Anaplan Solution Architect, leading the Center of Excellence at Globe Life.

Maybe you’re a new employee at a company who has been using Anaplan for a while, or maybe your company has contracted with an Anaplan partner to have some models built. Either way, it will be important to dig into the model and understand all of the moving parts: Data sources, Inputs, System modules, Calculations, Outputs, and everything in between. Why? Because it’s your model now and you will need to support it and your user base. (Yes, I did just reference the DISCO methodology! Read about that in this Community article — OEG Best Practice: Best practices for module design.)

For this blog, I downloaded and reviewed a template model from the Anaplan App Hub called Planning, Budgeting, and Forecasting for SaaS. As this model was built before the UX, the included dashboards are all classic dashboards. I created a couple of simple Pages in the UX for demonstration purposes only. The included spreadsheet contains exported details from the Actions, imports, import data sources, and modules components within the model. It demonstrates how the details can be filtered to find and isolate model specifics during your investigation.

The App Hub is available for Anaplan customers to download many useful training and example models.

Start here

Let’s take it step-by-step. First, take a copy of current production into your Dev environment. This allows you to walk through the model processes first as an administrator and then as each kind of user role to observe how the processes function by persona without potentially impacting your production environment.

Anaplan provides a very high-level model map that displays the model structure and interconnectivity, organized by mapped functional area. Therefore, the information organization is only as good as the mapping. When mapped properly, the diagram of functional area modules will enable you to identify how the data flows. Model map is accessible toward the bottom of the contents menu under the "…More" section.

When opening the model map, it can look a little daunting — just zoom in to review the module detail within each color-coded functional section. Each of the arrows between modules indicates the direction of data flow (“referenced by”), which can be helpful in understanding functional connectivity.

Image1.PNG

Alternatively, select the “Collapse all functional areas” navigation button to more easily view the connectivity between the functional areas. For example, see that the Strategic Planning functional area receives information from the Calculations & Technical, Parameters/Assumptions, and Sales/Revenue functional areas. In turn, it feeds back into the Calculations & Technical, Parameters/Assumptions, and Sales/Revenue, in addition to the Reporting functional area.

Image2.PNG

The Anapedia article about navigating the model map is here.

But this only indicates basic information flows. How does the model WORK?

Clearly, reviewing any user stories that are available will give you a good start. However, user stories are very high level by default and don't provide the “guts” of how the user story is accomplished within the model. Your model is still a big black box with some smaller boxes for each user story. Each of the smaller boxes need to be opened up for review!

Dashboard analysis

What task does the user story address and where does the user begin? Start with the dashboards! Similar to how a model design process begins, start with the user endpoints: dashboards, reports, and exports and work backward into the model through actions, views, lists, system tables, and data modules. Each of those will have targeted sources that the user works with to produce the desired output for the next stage.

Access the modules tab and review the “Used in dashboards” column at the far right. Similar to the “referenced by” column, this gives great insight into the sources of data to review when deconstructing a classic dashboard. In the example below, the Strategic Planning dashboard looks like a good place to start, as it is central to users accessing almost half of the modules in this functional area.

Image3.PNG

In addition to reviewing the module details within Anaplan, the descriptions can also be exported or simply copied and pasted into an Excel spreadsheet. This will be helpful if any dashboards span modules that are part of different functional areas and are therefore not grouped together. Once exported, filter for items that include the dashboard to analyze within the Used in dashboards column, and you’ll see all the displayed modules along with another key connection: Referenced by. Referenced by indicates that at least one line item in the module is being used by another module. You can also see this link from within the Blueprint view of the module itself. But when coming into the model from the outside and trying to map out the connections, this higher-level reference is useful. Please see the attached Excel spreadsheet for how I filtered the extract to identify these details (located at the bottom of this article).

Image4.PNG

So, in the Strategic Planning dashboard, we have A. data inputs, B. navigation actions, C. charts, and D. back-end “guts” of the application to run a process to lock or unlock a finalized scenario. If you didn’t build this model, how would you investigate and map out the functionality?

Image5.PNG

In each dashboard, there are object attributes that are shown or hidden, depending on the chosen object options. The “clean” appearance of the above dashboard hides the source modules, but you can temporarily display those sources for a screenshot by choosing “Show module name” in the options and then Preview the dashboard to see a production view without saving the changes.

Image6.PNG

Now you can review how graphical elements are configured, investigate how each line item is calculated based on data inputs, and follow any dependencies back to source data and system modules.

For each of the actions (both navigation and running processes), hovering your mouse over the button will show the action, the attributes of which can be researched in the Actions menu.

But, what about a published line item or other page element that doesn’t have a clearly defined source? For example, the element Scenario to Lock is a published line item — but from where?

Image7.PNG

In this case, the Model Search tool is the place to go. As you can see in the screenshot below, Model Search provides a list of all model components that contain the entered keywords. There’s a module, our published line item, two saved views, and another random module that happens to have all the letters in the keywords… we can safely ignore that one. 😉

Image8.PNG

All four of the elements in this section D of the dashboard are related to the Scenario to Lock module. The line items Scenario to Lock and Status both reside in the Scenario to Lock module. The Lock Strategic Plan and Unlock Strategic Plan processes run actions based on data in the Scenario to Lock module.

Image9.PNG

Processes and Actions

Let’s investigate Actions! The process Lock Strategic Plan contains Lock Actions 1–5 of 5 below and the Unlock Strategic Plan process contains Unlock Actions 1–3 of 3 shown below. We can see the description of these actions on the main Actions tab, but what are the specific sources and targets for these actions? What views are used? What are the parameters of the action (mapping, clear some or all, only update, what gets ignored, etc.)?

Image10.PNG

The sources and targets for these actions can be found by examining the attributes within the Imports and Import Data Sources tabs. Remember, these attributes can be exported or simply copy/pasted into Excel. Please see the attached Excel file for how I extracted and filtered the relevant tabs’ contents to isolate the relevant details within the next few screenshots below.

When reviewing the import attributes, be aware that the syntax of the Source Object field is Model / Module, so if the action was created using a non-production model and ALM’ed to production, the action’s Source Object will reference the original source model… which isn't likely to be the current source used by your production model. Review the current mapping in the Source Models menu within the Anaplan sidebar menu to get the current relationship. Remember that this relationship for the various source model instances must be managed as ongoing development is promoted, as new refreshed versions of “DEV” will change the model ID over time. DEV from 6 months ago may not be the same as DEV now and so no relationship between new DEV and PROD will be available in PROD until it’s mapped.

Since import data sources should be as narrowly defined as possible, this is often accomplished by creating a saved view to hold only the necessary line items (using SHOW) and filtered to meet a narrow import action requirements. If an action doesn’t function as expected, check out the filter applied to the source saved view to determine why a value in a target is not updated per the source. It’s likely there is a broken upstream process or a user’s selective access impacting the filter.

Back to the Import Analysis! See the import name in column A and the target object in column E. This lines up with your expectation based on the Actions tab.

Image11.PNG

Filtering the Import Data Sources extract by Imports (column F) will provide the exact list, module, or view Columns C Source Type and D Source Object Name to examine to understand the data flow.

Image12.PNG

Another item to remember is functional role permissions applied to the action. A perfectly reasonable user story includes a multi-function dashboard where users of different authority can input, review, and process information in the same place. If an end user can view a dashboard but shouldn't be able to run an action (like the ones we’re looking at, to lock or unlock a plan) then that user’s role should be unselected in Roles➡️Actions configuration screen. As you can see below, currently all functional roles in this model have the ability to run these actions and therefore the process composed of the actions.

Image13.PNG

You can finally review the configuration of the Action itself with confidence, as you know all the attributes of the Action! You know at least the basic user story associate with the process/action, you know where the source data is and where it’s going, and you know the action’s associated user permissions. Review the action configuration by choosing to “edit” the action and make note of the high-level source-to-target dimension mapping, the time dimension format, the matching of dimension members from the source to the target (and which are ignored), and the way in which the target data is updated or cleared depending on the mapped items by source.

This clearing part can be tricky, because the clearing piece isn’t global based on that first mapping screen shown below. But clearing is only available to configure on the subsequent tabs if the radio button to clear is selected on the first tab. It’s important to understand the nuance of how data is managed during imports and to play around with the options in a safe environment to understand which options impact the data in your own scenario, based on your source data and your target module dimensionality.

Image14.PNG

Considerations for UX

You might be thinking, what if we aren't using classic Dashboards? What if we’re in UX? Do I have to go into each page and look at each element to see where it originates? Well, the answer is, not anymore! Yes, friends, last fall, Anaplan enabled a view of the UX Pages where a model is accessed. Because a single App can include pages from various models across multiple workspaces, it’s not as fully centralized as the “Used in Dashboards” concept available in each model. Therefore, the App➡️Model and then Page➡️Model/Module relationships must be investigated separately. Action settings are viewed from the page (same as Classic), but the Page➡️Model/Module relationships can be found by following the steps outlined below.

First, find the model being used by the page.

Image15.PNG

Then, access the Pages menu from the sidebar menu within the model to review.

image16.PNG

Selecting the row of the page (not the blue page link, which will take you to the page itself) opens a menu with both General page information and Modules used by the page.

Image17.PNG

From there, the procedure to investigate action sources/targets/dependencies and module interconnectivity to understand how the module functions is the same as for classic Dashboards.

Review security

How does security play in? That’s a much deeper topic not addressed in detail here, but for Classic dashboards, all security is role-based. For UX pages, though, there's an ability to grant or restrict access to pages by role if desired. This applies to the page as a whole and is not specific to any underlying role-based module, action, or list permissions applied within the referenced model. These global page permissions can be viewed and managed in the page settings:

Image18.PNG

As you already know, role-based security is defined by the settings in the five Role configuration tabs of the User menu: Roles, Roles➡️Modules, Roles➡️Versions, Roles➡️Lists, and Roles➡️Actions.For either Classic or UX, if a process or set of functionality works fine for you (Full Access?) but an end user reports a bug, check permissions first. Module, list, and action permissions default to “No Access” and must be explicitly granted. Versions default to “Write” and must be restricted if needed.

With this, you are armed to discover and document your models’ functionality, dig into optimization strategies, and leverage the current functionality as a platform for new offerings that are sure to delight your customers. Happy modeling!

Referenced file attachment:

S_Gibbens_Anaplan_Blog_Excel.xlsx

Tagged:

Comments

Categories