Relabel the time dimension

Relabel the time dimension

As a model builder I want to have the ability to relabel the time dimension using a specific property/alias so that I don't need to create extra complexity and I can use all the benefits/functions of the time dimension to meet the users's requirements.

I will know this is successful if I could rename FY18 to YearXX and Jan1 to Month1, and so on.

Benefit : Adding extra lookups/modules doesn't always meet the visualisation requirements and adds complexity. Also, it will be possible to use the time dimension and all its functions even in situations where, for example, there is a strict requirement to "sanitise" the time dimension making it generic.

New Contributor

I would like to upvote this idea. We use the date format of 17-Jan-19 throughout our work and would like to be able to change all our dates in our Anaplan solution to this format.

Group Leader - Employee

In addition to relabeling months - it would be good to relabel the quarters as well.  Relabel the roll ups by Season (retail).  

Certified Master Anaplanner

Would also want to be able to rename to "Period 1" or "P1" and opt to show/hide the year. Will significantly reduce some models' complexity and remove many stories from backlogs.


Upvote, upvote, upvote! Great way to display data in the lingo that customers/users are used to.


I'd like to gauge the views of people on this thread on a narrower consideration around Time period labels. While we understand the drivers for a more flexible scheme, e.g. to provide 'aliases' for Lists generally, we have feedback that some customers have specific concerns around the 'FY' prefix used in the labels for aggregate time periods, e.g. for 'Q1 FY19' or 'FY19'.

In cases where customers would rather not see the 'FY' prefix used (e.g. because their model doesn't actually represent a fiscal year), would the option to use a 'CY' prefix instead be of value?

New Contributor

This is great idea, also would like to upvote!! my core customer really need this enhancement. I think we should have options to adjust local customer business practice.

New Contributor

We need this function. Please, please, please...!

Regular Contributor
Status changed to: Not Planned
Certified Master Anaplanner


Frequent Contributor

So is this abandoned or was it rebooted because of the recent status changes ?

I want to upvote that idea as well.

Not a dealbreaker, but the aliasing of time dim would be a good "nice to have"

Master Anaplanner/Community Boss


We are releasing functionality to allow you to change the 2 letter prefix for the time labels - This is due in August


On the wider relabelling question, I want to look at the alias concept across the whole model; I think there would be benefits for "labels" for all model structures, not just the timescales (although we could start there)



Certified Master Anaplanner

I'm a super fan of wider labels/aliases across the entire model. Glad to hear it's still on the radar!

Frequent Contributor

Awesome that we can now relabel years labels

Occasional Contributor
Status changed to: Delivered
Certified Master Anaplanner

Hi @DavidSmith ,

What's just been delivered is certainly a good step forward and I can see how it would help some customers.

However, further to my original idea I'm also attaching a diagram to help clarifying this idea further.


Could you confirm if this is already in the pipeline and/or if I misunderstood what's been delivered ?


@vicky_ascencio  , I noticed you changed the status of this idea to "Delivered", depending on what David says I would amend it accordingly.



Alessio Pagliano 

Certified Master Anaplanner

This is smth which'll help us a lot! 

We use custom week labels, which is critical for business. It makes us build intermediate modules on real timescale to run time functions and map back to fake timescale reports. 



New Contributor

Hi @david.savarin  san,


This is Nishibu from Japan.


Time scale format is fixed as "Mon YY" when uses Month scale. Most Japan customers are not familiar with that format. Then relabel functionality is definitely valuable for many Japan customers.



New Contributor

Guys - we definitely need this ability / flexibility for our corporate reporting.

I call it Aliasing - but relabelling is equally valid description. Think about it like this:- 

In a corporate world we are dealing with two or three types of stakeholder. 

  1. Real calendar time users require the columns of information to appear by month so they might see progress across time - perhaps multipe years. This appears to be the default time line that Anaplan has delivered. 
  2. Financial reporting is different.
    • The management and accountants see reports independent of the calendar month and are fixed in a corporate reporting time base. i.e. if the organisations accounts are from April to march then they would see columns of data by period (P1 equating to April, P2 to May etc).
    • This means quarters are tied to periods based on the financial year start i.e. Qtr1 is P1,2,3 not Jan, feb and mar.
    • To add to this they require the financial year to be included in the heading alongside the period. P1 by itself is meaningless unless it also states P1 FY 19/20 or P1 FY20/21. This format is the one I urgently need the system to auto produce. 
  3. Dynamic headings - similar to item 2 BUT....
    • Many calculations refer to comparisons with prior period or prior year - which is fine if your report is fixed in time i.e.  i report in May so prior period is Apr and next period is |Jun.
    • However when I report in June my prior period is May and next period July. The time headings should reflect this and change to Pn FY YY/(YY+1) without having to modify a static text header. I need the system to sort out the headings correctly based on the Pn YY/YY format and be able to change the heading automatically under programme control. Similar to a date field in Excel where you increment the period and Year in teh heading using an equation 

For what its worth the corporate time base above would be the standardised one used across the model - so we could set it as a systems policy - unlikely that we would use both types 1 and 2.


Hope this gets the point across - let me know if you need more