Best practices for revision tag documentation

amanda_myton

A revision tag is a snapshot of a model’s structural information at a point in time. Revision tags save all of the structural changes made in an application since the last revision tag was stored. By default, Anaplan allows you to add a title and description when creating a revision tag.

This article covers:  

• Suggestions for naming revision tags
• Creating a revisions tracking list and module

Note: For guidance on when to add revision tags, see When should I add revision tags?

 

Suggestions for naming revision tags

It’s best to define a standard naming convention for your revision tags early in the model-building process. You may want to discuss with your Anaplan Business Partner or IT group if there is an existing naming convention that would be best to follow. The following suggestions are designed to ensure consistency when there are large number of changes or model builders as well as allow the team to better choose which revision tag to choose when syncing a production application.

Option 1:

• 1.0 = Major revision/release
• 1 = Minor changes within a release

In this option, 1.0 indicates the first major release. As subsequent minor changes are tagged, they will be noted as 1.2, 1.3, etc until the next major release: 2.0.

Option 2:

• X = Major revision/release
• X.1 = Minor changes within a release

In this option, YYYY indicates the year and X indicates the release number. For example, the first major release of 2017, would be: 2017.1. Subsequent minor changes would be tagged: 2017.1.1, 2017.1.2, etc until the next major release of the year: 2017.2.

 

Creating a revisions tracking list and module

Revision tag descriptions are only visible from within Settings. That means that it can be difficult for an end user to know what changes have been made in the current release. Additionally, there may be times where you want to store additional information about revisions beyond what is in the revision tag description.

To provide release visibility in a production application, consider creating a revisions list and module to store key information about revisions.

Revisions list:

• In your Development application, create a list called: Revisions
• Do not set this list as Production. You want these list members to be visible in your production model

  

Revisions details module:

1. In your Development application, create a list called: Revisions Details
2. Add your Revisions List
3. Remove Time
4. Add your Line Items

Since this module will be used to document release updates and changes, consider which of the following may be appropriate:

• Details: What changes were made
• Date: What date was this revision tag created
• Model History ID: What was the Model History ID when this tag was created
• Requested By: Who requested these changes?
• Tested By: Who tested these changes?
• Tested Date: When were these changes tested?
• Approved By: Who signed off on these changes?

Note: Standard Selective Access rules apply to your production application. Consider who should be able to see this list and module as part of your application deployment.