The title block says revision B, the file name ends in "revC-final", and in the email to the customer the same file is called "latest version". Three sources, three answers to one simple question: which revision is this, actually? Whoever picks the wrong answer on the shop floor or in purchasing is sawing, ordering or assembling from outdated information.
That is not a matter of sloppy colleagues, but of missing agreements. Good revision management in Inventor comes down to three questions: what is a revision, where do you record it, and how does the rest of the company hear that something changed. In this article we lay out a minimal, sustainable way of working that a small department can actually keep up. Tooling such as the iProperty Panel from the Thundercad toolbox makes the bookkeeping easier, but the agreements come first.
What a revision is, and what it definitely is not
Not every change is a revision. As long as a part is still in design, everything moves: dimensions, material, entire features. Those are simply working versions, and they need no administration. A revision only starts to count after the first release: the moment others, production, purchasing, the customer, have started building on the document.
A usable definition: a revision is a released change to an already released document. Everything before that is groundwork. Give design iterations a revision letter too and you are at revision F before the first order, having hollowed out the numbering before it means anything.
Just as important is the boundary on the other side: not every change to a released part may be called a revision. The classic rule of thumb is interchangeability. If the changed part fits and functions everywhere the old one did, it is a new revision of the same number. If it is no longer interchangeable, it needs a new article number, not a revision bump. That single rule prevents the notorious situation where warehouse stock under one code exists in two non-interchangeable flavors.
Where to record the revision: one source, the rest follows
The chaos from the intro arises because the revision is maintained in several places independently. The fix is not paying closer attention, but appointing one source that all other places draw from:
| Place | Role | Pitfall |
|---|---|---|
| Revision iProperty | The source: this is where the revision is updated | Field forgotten at release |
| Title block | Shows the iProperty automatically | Typing it in by hand next to the source |
| Revision table on the drawing | History: what, why, when | Leaving it empty or filling it with jargon |
| File name | None: the name stays the same across revisions | A "revC-final" that contradicts the source |
The revision iProperty is the logical source: every drawing can display it, every export profile can carry it along and every search can filter on it. The title block reads that field and can therefore never contradict the model again. The file name stays the same through the years; a revision in the name is guaranteed to go stale and breaks references between files on top of that.
The weak spot in this list is the human step: the field does have to be updated. That is where the iProperty Panel from Thundercad helps: a configurable data card per document type that shows exactly the fields that matter to your team. With the revision sitting prominently on that card, updating it at release is one click and hard to forget.
Assemblies versus parts
For a single part the question is still manageable. It gets interesting with assemblies: should the main assembly get a new revision because a bracket changed three levels down? Without an agreement here, you end up either with an assembly that bumps at every trifle, or with an assembly that has sat on revision A for years while everything below it changed.
A sustainable middle ground in three rules:
- A part that changes gets its own new revision. Always.
- The assembly only bumps when something changes at its own level: the BOM (quantities, item numbers, substituted parts), the way it goes together, or the dimensions on the assembly drawing.
- An underlying change that is interchangeable therefore leaves the assembly alone; the new part revision can be traced through the part itself.
This keeps the revision of every level meaningful: it says something about that document, not about everything beneath it. And production learns that an unchanged assembly revision does not mean nothing changed anywhere, but that assembly can proceed from the same drawing.
Keeping track of revisions stands or falls with iProperties that are correct. With the iProperty Panel you update them in a structured way per document type, and after a revision change Batch Publish refreshes every affected drawing to PDF or STEP in a single run.
Try 30 days freeCommunicating a revision change to production and purchasing
A revision that only exists in the CAD system does not exist. The shop floor saws from a print or a PDF, purchasing orders from a STEP file or a drawing at the supplier. A revision change is therefore only complete when three things are handled: the new information has been distributed, the old has been removed, and the people involved know what to do with running work and stock.
That last part takes one sentence of discipline per revision. In the revision table, do not just write "hole moved", but also what the reader should do about it: existing stock may be used up, or must be blocked; a running order needs changing, or can proceed. That one sentence saves three phone calls and one wrong decision.
Removing old exports is the step that gets skipped most often, and exactly the step that lets revision A resurface on the shop floor months later. How to organize that cleanup, from export folder to email attachments, is covered in Cleaning up old exports, so production never builds from revision A.
The minimal way of working at a glance
It does not need to be more than this:
- Revisions only start after the first release; before that, only working versions exist.
- The revision iProperty is the single source; title block and revision table follow from it, and the file name stays free of revisions.
- For every change, first the interchangeability question: new revision or new number.
- Parts revise independently; assemblies only for changes at their own level.
- Every revision gets one line in the revision table: what, why, and what production and purchasing should do with it.
- After release: distribute new exports, remove the old ones.
If you also want to record which documents were released when, and who is allowed to do so, you arrive at state management. That is a subject of its own, with pitfalls of its own; we wrote about it earlier in Lifecycles and states in Vault: pragmatic, no more than you need.
Frequently asked questions
Does every small change need to become a new revision?
After release, yes, however small: a change without a revision bump is invisible to everyone working with the document. Before the first release, no; that is simply design work. So the boundary is not the size of the change, but whether others are already building on the document.
Why does the revision not belong in the file name?
Because the name is then guaranteed to lag behind the content at some point, and because renaming breaks the references between parts, assemblies and their drawings. The file keeps one name; the revision lives in the iProperty and is thereby visible on the title block, in exports and in searches. Export files such as PDFs are a different story, since those are disposable copies per revision.
Can Thundercad track revisions automatically?
Judging and bumping remains human work, and that is a good thing. The toolbox does make the bookkeeping faster and more visible: the revision sits as a fixed field on the data card of the iProperty Panel, and after a change you refresh all affected exports in one run. You can try it free for a month via the download page.