Would you spend weeks on your budget submission spreadsheet or your college thesis without once saving it?
Probably not.
The same should apply to making developments and setting revision tags. Anaplan recommends that during the development cycle, you set revision tags at least once per day. We also advise testing the revision tags against a dummy model if possible.
The recommended procedure is as follows:
There are a very small number of cases where combinations of structural changes cause a synchronization error (99 percent of synchronizations are successful). The Anaplan team is actively working to provide a resolution within the product, but in most cases, splitting changes between revision tags allows the synchronization to complete. In order to understand the issue when a synchronization fails, our support team needs to analyze the structural changes between the revisions.
Setting revision tags frequently provides the following benefits:
Synchronizations to the test model for R1, R2, and R3 were all successful, but R3 fails when trying to synchronize to production.
Since the test model successfully synchronized from R2 and then R3, you can repeat this process for the production model.
The new comparison report provides clear visibility of the changes between revision tags.
Hello
I have an issue which is not able to import models to another workspace due to the models have huge revision tags chain, therefore, I'm planning to break the current revision tags chain so as to import my models to another work space.
Woudl it be possible to recover the revision tags chain once it has been broken?
Hisashi Yamaguchi
One of the biggest challenges I have with my clients is that they are not clear as to what define as Production List and what is structural. I have seen some clients define all their lists as Production, while some clients will define alltheir lists as strucutural, as well as everything in between. Accordingly, many of clients have run into issues with synch errors or gaps in their model due to the lack of clarity on this subject. I have seen some documentation on definition of production vs. structural data, but it defintitely needs to be revisited as more clearly artiuclated as to what is best practice here.
thanks for the question.
For me, the answer is quite simple. There are two situations where lists should be set as production lists:
1. The lists are updated as part of an import; from a data hub or file
2. The lists are updated as part of the busines processes as part of the models, so adding Products to Promotions or accounts to Territories, or deleted as part of a clean up routine performed by users/admins. Numbered lists are a likely candidate for production lists, (but not in all cases)
In almost every other case the lists should be defined as structural.
It is better to set Structural lists first and then define as production later rather than the other way around; turning a production list into structural will remove data as the list is effectively deleted and re-added
I hope that helps clarify the situation
David
Is there a plan to pick and choose a specific set of items from the revision tags to move Production?