SOLIDWORKS PDM: Handling rejected design changes

A typical PDM workflow for revision controlled documents includes a ‘Pending Approval’ state for files that are being reviewed for approval.  This state normally allows the reviewer to either approve the proposed change and release the new revision, or to send the document back for further work – the assumption here is that the change would be accepted later if the required additional modifications are made to the document.

Typical workflow with transitions for approval and sending back

But there’s a catch…

What if the proposed change is simply rejected altogether?  What you do with the new versions that have been created in your model history once you have abandoned the proposed change?  In the following example, SW-201754 has been modified by adding some fillets.  As the version history shows, version 2 has been released as Revision A, but now due to the added fillets, there is a new version (3) which holds the change being considered for review.  If this change is rejected, the latest version no longer reflects the latest released revision.  This can confuse some users, especially if the change of version 3 will never be released.

Many companies will simply use the rollback feature of SOLIDWORKS PDM two put their design files back into the Released state and to remove the no longer needed versions.  However, rollback can be tricky and problematic; dealing with the versioning of referenced files properly and knowing what to do about parent references can cause confusion and lead to damaging mistakes that can’t be fixed easily.  Also, some companies prefer to keep their design history intact, so that it accurately reflects all of the changes that have been made to the design files – even if those changes were ultimately rejected.

But there’s an alternative to using rollback:  a little technique I call

the Leapfrog Maneuver

The Leapfrog Maneuver allows you to maintain Best File Management Practices which dictate that the latest version should also be the latest released revision for any file that is in a Released state.  To restore that condition now that extra unreleased versions have been added to the end of your file history, you need to create yet another version of the design (version 4, in this example) which has identical content to the last released revision, and the stamp the file with the current revision (not the next revision).  Here’s how that would look in the version history:

As you can see, version 2 has leapfrogged over version 3 and is now duplicated as version 4, and stamped again with revision A, creating version 5.

The steps for leapfrog maneuver are as follows:

1. Check out the file, which will get the latest version to your local view.
2. Now, get the last revision-stamped version (version 2 in the example), so that your local view reflects the actual released revision.
3. Then, check the file back in, creating a new version (version 4) whose design content is identical to the last released revision.
4. Finally, re-stamp the files with the existing revision.

The first three steps are easy, but the final step requires some modification to the workflow.  Here’s an example of a workflow with the modification to allow a rejected design idea to be bypassed using the Leapfrog Maneuver:

As you can see in the image, in addition to sending the file back for changes, there’s now a transition from the review state that can be used when the proposed change is to be abandoned.  This transition places the design files into a temporary holding state, in which the first three steps of the Leapfrog Maneuver are performed.  The transition from the Leapfrog state back to the Released state is where the magic occurs.  In this transition, the revision variable is reset to the value of the current revision counter (%revision%) and the revision counter is incremented by value of zero, causing the files to be re-stamped with the same revision they had before.

The one side effect of the leapfrog maneuver is that the file history shows two different versions with the same revision.  This may look strange at first, but a little logic and proper training allows users to understand that in this situation the actual revision A is the one with the higher version number; the one which occurs later in the files history.

Version 5 supercedes version 2 as the official Rev A

Every company must decide how best to handle aborted design changes.  The Leapfrog Maneuver provides an alternative to the simple yet sometimes problematic rollback. Leapfrog allows the design history to remain intact with the proposed but rejected design changes still available in the earlier versions, yet maintains proper file management by ensuring that the latest version is always the latest released revision.