OEG Best Practice: Revision tag best practices

AnaplanOEG
AnaplanOEG
edited February 2023 in Best Practices

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.

Little and often

The recommended procedure is as follows:

  1. After a successful sync to your production model, create a dummy model using the ‘Create from Revision’ feature. This will create a small test model with no production list items.
  2. At the end of each day (as a minimum), set a revision tag and attempt to synchronize the test model to this revision tag. The whole process should only take a couple of minutes.
  3. Repeat step 2 until you are ready to promote the changes to your production model.

RevisionTag_1.png

Why do we recommend this?

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:

  1. The number of changes between revisions is reduced, resulting in easier and faster issue diagnosis. 
  2. It provides an early warning of any problems so that someone can investigate them before they become critical.
  3. The last successful revision tag allows you to promote some, if not most, of the changes if appropriate.
  4. In some cases, a synchronization may fail initially, but when applying the changes in sequence the synchronization completes. Using the example from above:

RevisionTag_2.png

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.

RevisionTag_3.png

The new comparison report provides clear visibility of the changes between revision tags.

RevisionTag_4.png

Author David Smith.
Contributing author Bob Bachynsky.

Tagged:

Comments

  • hisyamaguchi
    hisyamaguchi

    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

  • mjpearlman
    mjpearlman

    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.  

  • DavidSmith
    DavidSmith

    @mjpearlman

    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

  • ram.venka
    ram.venka

    Is there a plan to pick and choose a specific set of items from the revision tags to move Production?

Categories