Version Settings as Production Data

DavidSmith

After the November 14th platform update, Switchover, Edit From, Edit To, and Notes will no longer be updated via an ALM sync. Spoke models will need to be updated individually via an import or the Anaplan UI.

The most optimal way to manage version settings going forward is by setting up module imports from a hub model.

Module imports are preferred over file imports for managing version settings. With file imports you have to be very careful to set up the date format; the format in the file needs to match exactly with the format displayed in the version settings, otherwise, the import will not update the target value. For example, when you export the Versions grid to a file (using CSV or TXT format), the switchover date will be exported as "MMM YY," but if Excel format is used, the format will be “MMM-YY." Similarly, if the CSV or TXT file is opened in Excel and then re-saved, the date format will convert to “MMM-YY”. Switchover date will not update if you re-import the file with this format. The date in the file needs to be in "MMM YY" format without the "-". For this purpose, we recommend that you use a module as a source for the import – see below for examples.

Remember that imports have to be set up in advance, as you cannot set up imports while in Deployed mode.

Examples:

A: Assume the same switchover date is needed for all spoke models.

1. In the Data Hub model:
   1. Create a module with line items to hold Switchover Date, Edit from/to (if required), formatted as months (see Planual rule 2.01-09 Use Lookup or Constants Module).
   2. Create a saved view to be used as the source of the import (see Planual rule 5.04-09).
2. In the Development model:
   1. Create an import using the Data hub module saved view (from 1b) as the source.
   2. Create a revision tag.
3. In the target model:
   1. Sync from the revision tag (from 2b).
   2. Run the import created in 2a.
4. Repeat 3 for each target model if applicable.
5. Your set up is now ready to update production version settings in Deployed mode!

B: Assume you need different switchover dates for different target models.

1. In the Data Hub:
   1. Follow steps 1a and 1b from example A above.
   2. Create additional line items and saved views for each different value as applicable.
2. In the Development model:
   1. Create the import as in 2a from example A above.
   2. Set the import data source as production data (see Production Imports).

   3. Set the import as production data.

   4. Create a revision tag.

3. In the target model:
   1. Sync from the revision tag (from 2d).
   2. Amend the Import Data Source as applicable.
   3. Amend the Import mapping as applicable - you will need to re-map the relevant line item(s).
   4. Run the import created in 2a.

   5. Repeat step 3 for each target model.

The steps can also be represented in the following diagram:

Contributing author Dafinka Pancheva.

andrewtye

And there was much rejoicing! No longer do we need to "go back to the future" and put on hold development work just to roll forward a model.

Noemi.andres

This new functionality is a great addition! I would love to see it going a bit further with versions being managed as Production Data entirely. The main benefit would be having less number of versions in DEV/TEST models than in PROD which would be more efficient and reduce the size of DEV/TEST models further. 

 

DavidSmith

@Noemi.andres 

We did look at that, but the Current flag can be referenced by CURRENTVERSION(), Version formulas and hard coded SELECTs which could cause an error on a sync.

We are still thinking of allowing it, but it will need "formula protection" logic (like we have for Production Lists).  From the feedback, Switchover period was the priority, so we kept Current as structural for the time being; we do want to explore versions generally as production data, so that will be a good time to include Current

David

jean-francois_l

@DavidSmith 

 

This is a feature that makes life easier for many administrators. Strongly, the full inclusion in Production data of the Version dimension.
Always high quality articles! Thank you.

 

DavidSmith

@jean-francois_l 

We are looking at Versions as production data.  The challenge is the formula protection, as mentioned above, but also the current reliance on SELECT:Versions.xxx, which will limit the usefulness.

We are planning to investigate this next year

David

PhilippErkinger

Fantastic and powerful new feature. Yet, I had to discover last week a major drawback at a customer that doesn't have a lot of headspace in the workspace

To add a new version, I had to reduce first the entire production model significantly. Then promote a revision tag with the new version. Add switch-over and ultimately reload the data.

 

@DavidSmith are you thinking of any further improvements to this new feature so it can be controlled by the model builder if its production or not? I'm thinking of production lists with the boolean..

 

DavidSmith

@PhilippErkinger 

Yes, that is something we are thinking about - When we get to allowing Versions themselves as production data, it is likely that we will include a boolean to allow versions settings as production data or not as desired

 

We are thinking of that too when it comes to allowing time settings and time ranges as production data 

 

David

PhilippErkinger

Any hint to when we can expect this? 🙂

DavidSmith

A little too early to say, but not likely until H2 2021 at the earliest, we've got other things higher up the priority list first

David