The project folder of a clamping unit holds three candidates for the title of "latest version": clampunit-final.iam, clampunit-final-v2.iam and clampunit-final-v2-REAL.iam. The engineer who created them knows exactly which one it is. Everyone after him guesses.
The standard advice at this point is a PDM system, but that is too easy: not every team is ready for one, and a purchase does not fix habits. Version control without Vault genuinely exists. It rests on four agreements: one project structure, strict naming, a read-only release folder and discipline around copies. This article lays out all four, including an honest answer to where folders stop and Vault begins. No new software required; at most a toolbox like Thundercad saves you some clicking and searching along the way.
Why versions go wrong on a shared drive
Version misery is rarely sloppiness. It grows out of behaviour that is perfectly sensible in the moment. Someone makes "a quick copy to be safe" before a big change. Someone emails an assembly to a colleague, who continues working on it. Someone takes work along on a laptop and puts it back on Friday afternoon. Three times well intended, three extra truths on the drive.
A shared drive does nothing to stop this. There is no lock preventing two people from editing the same part at the same time, no history that tells you what still worked yesterday, and no system that knows which of five identically named files the drawings actually use. Everything a PDM system enforces has to come from agreements here. That can work, but only if the agreements are explicit, and carried by everyone.
Agreement one: the same project structure everywhere
Grip starts with predictability: every project gets exactly the same skeleton. For example a working folder for the living Inventor files, a release folder for what went out the door, and an obsolete folder for what used to be true. Whoever knows the way in project A then knows it in project B, and a file outside the skeleton immediately stands out as a stray.
The most important rule inside that skeleton: a working file exists in exactly one place, the working folder of its project. Not also on a personal drive, not in a folder called "old", not on a desktop. How to set up the technical side, with workspace, libraries and the project file, is covered in Order in your Inventor project folders: workspace, libraries and project file; for version control what matters most is that it is the same everywhere.
Agreement two: naming without final-v2-REAL
File names are where version control without a system visibly derails. The remedy is a small, hard set of rules:
- A working file never carries a version number in its name. There is only one of it, and it lives in the working folder.
- Words like final, new, old, copy and REAL are banned from file names. They describe a moment, and moments expire.
- A revision marker exists only on released output: the PDFs and STEP files in the release folder carry a revision letter in one fixed pattern.
- When a release becomes obsolete, it moves to the obsolete folder. Renaming it in place is forbidden: that is how assemblies and drawings lose their references.
Agreement three: the release folder is read-only
The release folder is the heart of this way of working. It holds what went to the shop floor, the customer or a supplier: PDFs, STEP and DXF files, ordered by revision. Everyone can read it and almost nobody can write to it; through the permissions on the network folder you arrange that only one or two people can put anything in.
That single restriction changes the game. The shop floor and purchasing never look in working folders again, because everything that counts is in the release folder. The question "is this the right version?" gets an address: if it is in the release folder it is released, otherwise it is not. And because nobody can casually write to it, a hectic Friday afternoon cannot quietly change its contents.
Releasing becomes a small, deliberate act: export, check, place in the release folder, move the old release to obsolete. If you like, note one line per release in a simple log: date, what, why. It does not need to be more administration than that.
In practice, releasing mostly means exporting and filing things neatly. With Batch Publish and Export Folder from Thundercad, a complete set of PDFs and STEP files lands in the right place in your release structure in one run.
Try 30 days freeAgreement four: discipline around copies
Copies are the back road along which all the misery returns, so they deserve rules of their own. A copy is allowed, but only as an experiment, in a personal scratch folder, with a clear name and a short shelf life. A copy never goes back over the original; whoever wants to keep something from an experiment builds it into the working file deliberately. External deliveries are made with a pack-and-go, never by zipping the working folder. And nobody continues working on a file that arrived by email: that is frozen history.
Also plan a fixed clean-up moment, for example at the end of every project: scratch folders emptied, strays back into the skeleton or gone. Discipline wears down under pressure; a recurring moment when someone sweeps through keeps the agreements alive.
Where agreements stop and Vault begins
Let us be honest: this setup has limits. It has no check-in and check-out, so two engineers working in the same assembly at the same time remain a risk you can only cover by talking. It has no history: an overwritten working file is gone, and last night's backup is your only net. It does not know where a part is used, so reuse across projects stays manual work. And agreements wear out: every new colleague and every peak week tests them again.
When the team grows, when several people work in the same assemblies daily, or when customers ask for demonstrable control of revisions, the point approaches where folders and discipline are no longer enough. When that point is truly reached, and what a move involves, is covered in Do you need Vault? An honest answer for smaller teams. Until then: four agreements, kept consistently, save you most of the version misery.
Frequently asked questions
Is a read-only release folder not just Vault in miniature?
It borrows one principle: released output is protected and has a single address. But check-in and check-out, history and where-used information are completely absent. So treat the release folder not as a replacement for PDM, but as the biggest step you can take without a system.
What do I do with existing files full of -final and -v2?
Do not rename them retroactively: Inventor assemblies and drawings refer to those names, and mass renaming breaks references. Freeze finished projects as they are and apply the new rules to everything that starts from now on; only clean up active projects, and do it deliberately.
Can we start this without disrupting running projects?
Yes, and that is exactly its strength: you introduce the agreements per new project, without migration or downtime. Start with the skeleton and the release folder, because those two catch most of the errors. Speeding up the exports into that release folder is possible right away; the free 30-day trial of Thundercad is enough for that.