If tracking a secondary revision value, the revision history output on cover pages can be set up to show only the secondary revision record. This is useful when a template includes two revision history tables: one that lists all revisions, and another that lists only unique secondary revisions. In this case, SEND records should not be disabled from the card history, and filtering the secondary revision table is the best approach.
Filtering the secondary revision table can be accomplished by setting up an array for each distinct revision, filtering each array by the secondary rev, and sorting in either ascending or descending order.
Example: The cover page template includes two pages, each with a revision history table. The first page should include ALL revisions, but the second should include only unique secondary revisions.
For the secondary revisions table, the customer is looking to see the most recent revision record. As such, each array should be sorted in descending order.
When the primary rev is updated and the secondary rev stays the same, the revision record will generate the secondary revision with the date updated (reflecting the most recent date).
The format for the "Start" array variable is as follows, with the "X" being updated to reflect each secondary rev value, and the sort order being defined (either ascending (ASC) or descending (DESC)).
<Start_Document_History|IncludeCurrent|Filter("SecondaryDocRev",["X"])|SortOrder=ASC/DESC|count(1)>
This combination of the array start variable, the regular revision history variables, and the array end variable will then be repeated to accommodate for each secondary rev value.
Note: Each revision "grouping" will only populate data for secondary revision values that exist in the card history. If the value does not exist (e.g., the secondary rev is "1" but there are groupings set up for values 0 through 4), the row will still appear but will be blank.
If the template requires a specific number of rows in the revision history table, the minRows=X parameter should not be used, as this would result in empty rows between each revision. Instead, simply set up a revision "grouping" for the number of rows that are required.