During a setup session, a CAD administrator confidently sketched seven states on the whiteboard: concept, in work, under review, approved, cleared for work preparation, in production, obsolete. Every box got arrows, every arrow got a rule. Half a year of daily practice later, the verdict was in: the team used three of them, and nobody could remember why the other four existed. Files hung in "approved" for days because it was unclear who owed the next click.
You see that pattern a lot with Vault lifecycle states: the setup gets designed for the process as it should look on paper, not for the five people who work with it every day. In this article: a minimal setup that covers nearly any small engineering team, who performs which transition, how states relate to revisions, and how to spot over-engineering before you walk into it. Tooling such as Thundercad mainly speeds up what happens after release; the lifecycle itself you set up with common sense.
Two questions a state must answer
Strip away all the theory and a document state answers just two questions. One: may this be worked on? Two: may the rest of the company build on it? Anything else a state communicates is decoration. A state like "being discussed with the project lead" changes the answer to neither question and therefore does not belong in the lifecycle; that is progress information, and it lives perfectly well on a task list or project board.
Test every proposed state against those two questions and the chaff falls away by itself. What remains is surprisingly little, and that is precisely the point: every extra state means extra clicking on every change, extra explaining to every new colleague and extra opportunity for a file to get stuck somewhere.
The minimal setup: three states and a terminus
For most teams in machine building and sheet metal, this is enough:
| State | Who may edit | What everyone else may do |
|---|---|---|
| Work in progress | The engineer | Nothing: anything can still change |
| Under review | Nobody (frozen) | View and judge, not build on it |
| Released | Nobody | Order, manufacture, assemble |
| Obsolete | Nobody | Consult as reference only |
Work in progress is home base: the engineer works, nobody else counts on anything. Under review freezes the file, so the reviewer is not judging a moving target; if something gets rejected, it returns to work in progress with a remark. Released means: this is the truth, you may order and build against it. Obsolete is the terminus for whatever must never be used again but is kept for reference. A team of three to ten engineers rarely needs more flavors than that.
Who performs which transition
A lifecycle only becomes a process once the transitions have owners. Here too: keep it small. Submitting for review is something every engineer does themselves; there is no risk in it, at worst a reviewer sees something slightly messy slightly early. The transition to released is the only one with real consequences, because money gets spent on the file afterwards. Assign it to people who also carry that responsibility, and make it at least two of them: a single approver means everything stalls with every holiday and every flu.
The most dangerous transition is the road back: making a released document editable again. Deliberately make that one heavy and place it with the administrator or team lead. Not because colleagues are untrustworthy, but because the threshold forces the right question: should this not simply become a new revision? Casually rolling back erases the certainty that what the shop floor printed yesterday is still valid today.
After release, nobody on the shop floor wants an Inventor file; they want PDFs and cutting files of the released state. With Batch Publish from Thundercad you publish drawings in bulk to PDF, DWG, DXF and STEP, and it works together with Vault.
Try 30 days freeStates and revisions: keep the roles clean
State and revision touch each other at release, and that is where the confusion usually starts. Keep the roles simple: the state says where the document stands in the process right now, the revision says which issue of the design this is. At release the revision should increment; if you want to change something afterwards, the next revision starts with the new edit and travels the same lifecycle again. That way work preparation can always say: revision C is released, revision D is on its way.
Above all, do not bake revision information into state names ("released rev B") and do not use states to administer old issues; that is what revisions are for. How to organize that side properly, with change reasons and a trail you can follow afterwards, is covered in Keeping track of revisions without the chaos.
How to spot over-engineering
An overweight setup rarely announces itself as a problem; while designing it, it feels thorough. These signals give it away in practice:
- Nobody can list all the states from memory, including the person who invented them.
- Files hang in an intermediate state for days because it is unclear who has to click.
- There are states per department ("waiting for purchasing"): that is task management, not document status.
- The administrator regularly flips states by hand because the process "does not fit".
- Explaining the lifecycle to a new colleague takes more than one sheet of paper.
Recognize two or more of these, then simplify. Doing it in steps is fine: merge states, drop transitions, widen permissions. And when in doubt, always start smaller than you think you need: adding a state when the process asks for it is fifteen minutes of work, removing a state that hundreds of files are sitting in is an afternoon of puzzling. More lessons of this kind for teams that recently started with Vault can be found in Five Vault pitfalls for teams that just started.
Frequently asked questions
Do I need a separate state for prototypes or projects?
Usually not. Whether something is a prototype, a customer project or standard work is a property of the project or the folder, not a process state. A prototype travels the same steps: work on it, review it, release it for the build. Maintaining two lifecycles for the same rhythm is double administration with no gain.
What do I do with existing files when I simplify the lifecycle?
Make a mapping table from old to new: everything that was released stays released, all intermediate states become work in progress or under review. Run the conversion in one go, outside working hours, and tell the team beforehand which state landed where. It feels like a big step, but it is bookkeeping; the designs themselves do not change.
How much time does such a minimal setup take?
As an assumption: the setup itself is an afternoon of work, and the team gets used to it in a week or two. The biggest time gain comes afterwards, in publishing: pushing released work to the shop floor and suppliers in bulk. Want to get that part right from day one: try Thundercad 30 days free.