One Lifecycle Definition - called Flexible - contains a nifty optional state called Quick change. Like the name implies, modifications made whilst in this state should be done quickly and the file returned to a formal Released status.
In my travels demonstrating and implementing Vault Workgroup/Collaboration/Manufacturing, this Quick change state has caused stir and churn within engineering groups. To understand this, let's examine some of the intended rules with Quick Change.
In a typical transition from Released to Work in Progress, there is a rule that bumps the revision level forward - A to B, 1 to 2, etc. This primary bump in revision is meant to reflect a form, fit, or function change.
There is a case where files need minor modifications like spelling corrections and this is where Quick Change comes to the rescue. Upon transition from Released to Quick Change, there is no bump in revision, yet the file security matches that of the Work in Progress.
This makes for a nice option, but it does pose questions: who should be able to perform this? how do we keep track of this? how does a design team keep this from becoming a major loophole?
The good news lies in the configurable nature of Vault. In the transitions settings, admins can manage exactly who can make the transition to Quick Change. Remember that managing user in Vault is best done with Groups, and one option would be to limit this action to admins, project leads, managers, etc. This means the CAD users would not even see Quick Change as an optional state during transitions. The benefit here? Quick change would be used sparingly by users with the responsibility to know when a file needs a rev bump or not. The down side? These users will bear that additional effort of making quick changes.
Another solution here would involve letting CAD user level groups execute the Released to Quick Change transition, bypassing the rev bump. Yet keep the Quick change to Released option for the admins, project leads, and managers mentioned above. This provides a nice check and balance and ensure the Quick change state does not become a loophole lifecycle state.
One final thought on Quick Change is to allow a transition from Quick Change down to Work in Progress. This transition would bump the rev and should be open to CAD users and admins alike. Think of this a nice option for those times where file modification starts out as a 'quick change' to files and turns into something larger, thus warranting a full rev bump.
And when it comes to tracking this, the History tab in Vault will show when the file was moved to Quick Change, who made the change, and so on.