Setting up Vault: a folder structure and naming that grow with you

The folder structure you set up in Vault on day one will last for years. Not because it is that good, but because relocating afterwards hurts: references, search paths and habits grow onto it. Whoever creates the first layout "real quick" just to get started will still be working around it years later.

This article is about that first layout: the trade-offs behind a Vault folder structure setup that grows with your company. From the main choice between project and product folders to how deep a tree may go and which naming convention prevents endless searching, with a compact starter structure as a point of departure. The layout itself is thinking work you want to do well once; the daily navigating and publishing inside it is what a toolbox like Thundercad speeds up afterwards.

Coming from loose Windows folders? The move itself is a story of its own, which we covered in From Windows folders to Vault: making the move without drama. Here we focus on the structure you build inside Vault once that decision is made.

By project or by product type?

The first and most important choice. For a machine builder doing customer-specific work, a project structure feels natural: one folder per order, everything for that order together. For a company delivering variants of the same products, a product structure makes more sense: the product is the constant, orders come and go.

Both flavours have a downside. A pure project structure hides reuse: the frame that worked fine last project is buried in that old project folder, so someone copies it into the new project "to be safe", producing duplicate files and diverging versions. A pure product structure leaves customer-specific work floating: where do you put the one-off special that fits nowhere in the catalogue?

In practice a hybrid works best: one branch for everything you reuse (products, standard parts, libraries) and one branch for everything tied to an order or customer (projects). Unsure where your centre of gravity lies? Look at how sales sells. If you sell orders, the project branch dominates; if you sell configurations from a catalogue, the product branch does. The structure should follow the work, not the other way around.

Libraries and standard parts: separate and protected

Anything you reuse never lives in a project folder. Standard parts from the Content Center, purchased parts with their own part number and your own standard components such as frames, clamping plates and platform stairs get their own library branch. There are two reasons. The practical one: everyone knows where the released, ready-to-use parts live, so nobody has to dig through old projects. The governance one: a library carries stricter permissions, so a standard part does not get tweaked "just for this project" while twenty other assemblies reference it.

Keep the library small and guarded: something only enters once it is released and named according to the convention. A library everyone writes into freely is simply a second project folder within a year. How workspace, libraries and the project file relate on the Inventor side is covered in Order in your Inventor project folders; that foundation still stands when Vault comes in.

How deep may the tree go?

Rule of thumb: three levels below the root, four at most. Every extra layer means extra clicks, but above all extra doubt. The deeper the tree, the more often two colleagues store the same kind of file in different places, simply because there are more junctions on the way down to choose slightly differently. Deep structures also come back in the local working folder, where very long paths eventually cause trouble.

Wide beats deep. Better eight clear folders side by side than a neatly nested five-layer logic nobody navigates without thinking. The test is simple: if you have to think about which level something belongs on when saving, the tree is too deep or the rule is too vague. Searching by properties covers the rest; the tree does not have to answer every conceivable question, only the daily ones.

A useful benchmark is the new colleague. If they can store and retrieve files on their own after a ten-minute tour, the tree is fine. If it takes a three-page explainer, the structure is the problem, not the colleague.

Naming that prevents searching

File names first, because one rule is sacred there: every file name is unique across the entire Vault. Inventor resolves references by file name; two different parts both called "plate-01" are an invitation to swapped references. Beyond that, sober works best:

• Use the part number as the file name and put the description in the iProperties, not the other way around. The name is for the machine, properties are for people.
• No versions, dates or "final" in the name: version control is exactly what Vault already does for you.
• Give top-level folders a fixed number prefix (01 Libraries, 02 Products, 03 Projects), so the order is the same everywhere and new folders do not shuffle in between existing ones.
• Start project folders with the project number, followed by a short description; they sort chronologically by themselves and everyone finds them by number.
• Avoid abbreviations only one department understands. A new colleague should be able to read the tree without a dictionary.

What should go into that part number itself, meaning or deliberately none, is a discussion of its own that we leave aside here. For the folder structure only one thing counts: there is one convention and everyone follows it.

A starter structure that grows with you

As a point of departure, deliberately kept compact:

Six branches, no more. New product groups and projects grow on their own level without touching the logic. What you should not do: create empty folders in advance for every conceivable case. Empty folders invite personal interpretations, and personal interpretations are exactly what a structure is meant to prevent.

Guard the structure actively during the first weeks: spend fifteen minutes a week walking through the new files and move anything misplaced right away, inside Vault and therefore with references intact. A tight tree pays off daily after that, all the way to release: with Batch Publish from Thundercad you publish drawing sets in bulk to PDF, DWG, DXF or STEP, working directly together with Vault, without anyone having to walk through folders.

Frequently asked questions

Can we still rearrange the structure later?

It is possible: inside Vault you move files while keeping references intact. But it remains work, it breaks search habits and people adjust slowly, so in practice it rarely happens thoroughly. Consider the afternoon of thinking beforehand the cheapest renovation you will ever do.

Where do customer specials go in a product structure?

In the project branch, even when the special consists largely of product parts. The special's assembly is order-related and belongs to the project; the reusable parts underneath simply stay in the product branch and are only placed. Reuse stays visible and the product branch does not get polluted with one-off work.

What difference does a good structure make in daily work?

Less searching, fewer misplaced files and a release that does not start with walking through folders. The navigation that remains is what you automate with Go To Folder and Frequent Folder; you can try those, together with the rest of Thundercad, free for a month via the download page.