A new colleague opens an existing assembly on his second day. Inventor greets him with a resolve dialog: seventeen references not found. An hour of digging later, half the parts turn out to be scattered across three folders, one of which is called "old_do_not_use" and is still very much in use. Nobody planned it this way. It just grew.
Half of all CAD misery starts right here: with a messy folder structure and a project file nobody ever set up deliberately. Broken references, duplicate parts, library components someone "quickly" modified: they are symptoms of the same disease. In this article we lay the foundation: a clear Inventor project file and folder structure, libraries that are genuinely read-only and an example layout you can copy. A toolbox like Thundercad then helps you move through that structure faster, but the setup itself is thinking work you do properly once.
Why the project file matters so much
The project file (.ipj) is the map Inventor uses to find files. It defines where the workspace lives, which libraries exist and in what order Inventor searches when opening an assembly. If that map is wrong, Inventor does not find the part, it finds a part: the first hit with a matching file name. If "plate_5mm.ipt" exists three times on your drive, the search order decides which version ends up in your assembly. That goes well for a long time, until it silently goes wrong and the wrong plate shows up on a drawing.
Most reference trouble is therefore not an Inventor problem but a setup problem. Get the folder structure and project file right and the resolve dialog becomes a rare sight.
The workspace: everything for one order in one place
The workspace is where your own designs live. The rule is simple: everything belonging to one order or project sits under a single project folder inside that workspace. No parts on personal drives, no "temporary" desktop folder that survives for years, no copy in an e-mail as a safety net.
Within the project folder, a layout per module or main group works well: frame, drive, enclosure, controls. That keeps an assembly with hundreds of parts manageable, and the logic in Explorer mirrors the logic in your model tree. Also agree that an order folder is locked after delivery: from that moment on, what is in it is the truth of that project.
Libraries: read-only is a feature, not a nuisance
Library folders in the project file are read-only, and that is exactly the point. A library holds parts that appear in multiple projects: standard hardware, purchased components, profiles, your own standard modules. If you could edit them from within a project, one "small tweak" for machine A would silently change every earlier machine containing that part.
The classic example: an engineer makes a library bracket twenty millimeters longer because it suits his project better. Three weeks later a colleague opens an older machine for a revision and none of the hole patterns line up anymore. So work with a fixed agreement: a library part that does not fit gets copied into your project folder under a new number, or you have it changed deliberately, and documented, by the library's owner.
One project file for everyone, not one per job
Inventor tempts you to create a new project file for every job. Before you know it, every engineer has a personal .ipj with personal paths, and the same file behaves differently for everyone. Switching project files all the time also switches your library references along with it, and that is asking for broken links.
For most companies a single central project file works best: one .ipj on a network location, with the workspace pointing at the shared projects folder and every library listed in it. Everyone reaches the files through the same path, so references resolve identically for everyone. Separate project files are the exception, for instance when customer data must stay strictly separated. In every case, appoint one person to manage the project file: it is company tooling, not a personal preference.
One thing a project file does not handle is version control. Who changed what, and which version went to the shop floor, is a separate discipline. Not running Vault yet? Then also read No Vault yet? Keeping a grip on your versions anyway.
A tight structure pays off every single day: less searching, fewer broken references, no surprises when opening old projects. Curious what an organized environment does to your pace in practice?
Try 30 days freeAn example structure proven in practice
There is no sacred layout, but there are a few principles: order number first, no spaces or special characters in folder names, and never two places for the same kind of file. This setup shows up, in several variants, at many machine builders:
- Projects\ with one folder per order: order number plus a short description, with folders per module below it (frame, drive, enclosure).
- Library\StandardParts\ for bolts, nuts, washers and other standard hardware that never changes per project.
- Library\PurchasedParts\ for bought components, grouped by type, with the article number in the file name.
- Library\StandardModules\ for your own recurring constructions that you drop in as fixed blocks.
- Templates\ for templates and title blocks, so new files start from the same base everywhere.
Note that this is the source-file side of the story. PDFs, DXFs and other outgoing files deserve their own, much flatter layout; you can read more about that in an export folder structure everyone understands.
Navigating your own structure quickly
A good structure is inevitably a few levels deep, and that means clicking: from Inventor to Explorer, open the network drive, find the project folder, open the module. Do that twenty times a day and a quarter of an hour is gone. That is what Go To Folder in Thundercad is for: one click and you jump from the open file straight to the right folder in Explorer. With Frequent Folder you also pin the folders you use all the time, such as the library or the current order folder.
It sounds like a detail, but exactly those small navigation moments decide whether your structure survives. The lower the threshold to land in the right place, the smaller the temptation to "just quickly" park a file on the desktop.
Frequently asked questions
Do I have to migrate existing projects to the new structure?
No, start with new orders. Move old projects only when they are opened for a revision anyway, and then do it properly: relocate, repair references and clean up the old location. Converting everything at once costs days and mostly produces risk.
What do I do with a part that appears in several projects?
Promote it deliberately to the library: its own number, its own location, read-only. From that moment you change it only through the library owner, so existing projects never shift underneath you. Copying it into every project folder looks easier, but then you end up maintaining five variants of the same part.
How do I keep the structure from eroding after a few months?
Keep the agreements small and visible: one sheet with the folder logic, one owner for the project file and a short check when closing out each project. And lower the threshold for actually using the structure: with the free trial month of Thundercad you will notice how much it helps when the right folder is always one click away.