This guide will walk through the Time setting in Anaplan models, as well as some best practice recommendations on automating the current time period to simplify formulas and dashboard views.
The Time setting is a critical component of the model structure and should factor in long-term objectives and the purpose of a new model. Once established, it can be difficult to go back and change in a production model without causing significant impact, such as potential data loss.
The basics of the Time setting allow you to set the default type of calendar (monthly vs. weekly), as well as set the start month for the fiscal year, the current year, and an option to set the current period. I’m going to skip the current period option for now and later demonstrate how we have automated this process in most of our Anaplan models, and explain why.
It’s important to map out your long-term objectives of the model when looking at the number of past and future years. If you decide to change this after going live with a production model, it can be more challenging to populate past data if needed for analysis. At the same time, you don’t want past/future years if they are not required for your business needs. Adding irrelevant years in the model can increase model space and processing time for any line items dimensionalized by month if you do not monitor the time ranges.
For example, in the model below, I only care about sales quotas in the current year. If I set my model up to include past year data that I’m not tracking, any module that is dimensionalized by month will take up space and processing time calculating 0’s in past months that aren’t necessary. To mitigate this problem, you should focus on setting your model up only for the time ranges that you need data for.
Alternatively, you can set a time range for a subset of months and then customize modules and/or line items accordingly to keep model efficiency. In this model example, I have both a current and one year of past data, but some modules I choose to dimensionalize by only the current year’s data. This is done by setting up a time range in the settings:
I mentioned above that I don’t set current period in a lot of my models. The reason for this is because we have chosen to automate the current period in order to streamline the monthly rollover process in our calculations. When it comes to time, the only thing we need is a single input feed: Current Date. We have this auto fed daily through our Anaplan Connect jobs, and from there we have created various time periods that we use in either our data comparison or time calculations. I’ll walk you through what we have set.
In each model we create, the first module we establish is a Date module. Here, we have our Current Date, which is fed from our Enterprise Data Warehouse (EDW) each morning. When importing the date, it’s important to do this outside of busy hours for your organization because this drives and updates calculations in the models. Our import is started before working hours so that it is complete when users log into the models in the morning. We then establish the current date, current month, current year, prior month, and prior year. The formulas are outlined below, and with the automation of our current date, we never need to update the day/month/year in the model to be accurate. Keep in mind our organization has standardized on one date regardless of location, this is an important fact if you are a global organization and can have people on different dates due to time zones.
The biggest benefit for our organization with this approach, besides the automation of dates, is that it simplifies many formulas throughout the model by using basic lookup functions. If users are building out a module and need to include the numbers from the current month, they can simply point to the module storing the data and do a quick [lookup: date.month] or [lookup: date.current year]. The summary function on the line item will auto sum the numbers when we are looking up a full year or any other time range we have defined.
The second module we establish is a time filter. This module is what makes our lives easier when it comes to dashboard building and comparing data from various time ranges. It is also one of the easier concepts for our business users to onboard and allows them to create their own unique time ranges based on their model needs.
Almost everything we use is set in the format of Boolean checkboxes. From here we use fairly simple (although they can get lengthy) formulas to establish time ranges by month—things like Current Year (CY), Prior Year (PY), Year to Date (YTD), Year to Go (YTG), Trailing 12 months (T12), Trailing 3 Months (T3M). As you can imagine, we have a lot of flexibility in the types of ranges we create, and these are the foundations that drive a majority of our calculations and dashboard views.
For calculations, we then build out modules dimensionalized by month, and we can reference the time filter module to form the calculations below.
Since the Date is automatically updated daily, this then updates all calculations and time filters as each month rolls over without any interaction from users. In June, the trailing three months are March, April, May. When the date switches to July 1, it knows that the trailing three months are now April, May, June, and all comparison data is automatically updated. We analyze things like how much quota is left in the year vs. how much has been given out which is determined by the YTD and YTG line items in the screenshot above.
These time filters are also the primary driver of our dashboards. When we want to filter our data to show business users data from the current month, we set the filter to be based on the Current Month line item of our Time Filter Module. When the month rolls over, the dashboard updates with it.
Another use case is when we export monthly data, we only want to export the current month and future months. Again, this is determined by a time filter so that past data never gets changed. The example below was taken from our model in October:
Our organization has also found this to be an effective alternative to Forecast vs. Actuals in many cases. We define our Actuals Periods with “ITEM(Time)>= Date.Current Month”.
The moral of the story is, don’t overlook the small stuff in Anaplan. The Time Setting aspect may seem like a quick and basic part of establishing a new model, but with one automated daily feed, it is arguably the most important aspect of all models we create and the easiest for our model builders to customize.
... View more
Yep, I just found it. There were manually saved views it looks like that had hand picked the teams by segment for each of the dashboards. Not a good solution for us because new teams come/go monthly and this is a data management nightmare. Using the lists is much better since everything is controlled by user access to the hierarchy levels, and it basically accomplishes the same views but auto updates. Thanks for helping!
... View more
@KeithJackson Confirmed access isn't an issue. Write access to the top level of the hierarchy. our L4 is Area, and under this Area there are 5 teams now in the hierarchy, but only 4 are displaying on the dashboards as a drill down If I filter down to the L4 Area, I can find members who belong to the new team in question using the search (let's say John Smith). If I drill into each of the 4 teams listed under L4, I can't find John Smith in any of them. This is expected since he is on that 5th team that isn't an option to select. I'm trying to dissect how the team published the list selector when this model was built, because I wasn't involved. I tend to use the list from the hierarchy so it stays in sync with updates, but they may not have done it this way.
... View more
Thanks Rob. I checked for filters as well, but it's the Master dashboard that isn't syncing. If I go one level higher in the hierarchy page selector, I can see the end users that currently live on the new team, but I can't select that specific team at the L5 level. I have checked the module as well and there are no filters that would exclude them from being displayed.
... View more
One of our new models is behaving differently in regards to the page selectors on the dashboards, and I'm trying to determine if it is due to the feature of enabling personalized views (this is the only model we allow personal dashboard views). In two models we have L5 List as Teams from the hieararchy, and have this list published as a page selector. The hierarchy is updating correctly and this month one team changed it's name, so we now have the new record in L5 since we do not delete our hierarchy. In the main models, the page selectors are working correctly and we can see the new team automatically. The other model which allows personal views, the list page selector does not show the new team. If I republish the L5 list to the dashboard it will update correctly, but this will wipe everyone's views. Any thoughts?
... View more
Thanks David, Yes I can get the file name because it appears we are uploading the exact same file every day, but we run a script to delete the file (or remove it) from the file location after the job is run, then replace it again the following day when the update occurs. If I manually load the file, and map the fields, will I have to update the Connect script to continue the daily load?
... View more
My data hub currently updates an Account Property module nightly with 5 attributes. I am looking to bring in two more that I can then send to my goal setting model. When I go to the Action to edit it, I get an error that the file no longer exists. I've made two columns in the Properties Module that match exactly to the names of the two columns that IT has added to their view. My question is how do I update the action to map these new columns, or will it happen automatically if the column headers match? We are about a week out from the view being deployed into production or I would simply test this, so I'm trying to do what I can now.
... View more