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.
A: Assume the same switchover date is needed for all spoke models.
B: Assume you need different switchover dates for different target models.
Set the import as production data.
Create a revision tag.
Repeat step 3 for each target model.
The steps can also be represented in the following diagram:
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.
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.
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
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.
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
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..
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
Any hint to when we can expect this? 🙂
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