Building file names automatically from iProperties

What is inside "plate_left_final2(1).pdf"? No idea, and that is exactly the problem. The buyer guesses, the shop floor prints two versions just in case, and you spend Friday afternoon working out which of the three "final" files is actually final.

A good file naming convention for drawings fixes this: drawing number, revision and description in the name, so the file itself tells you what it is without anyone opening it. In this article you pick such a convention, put the source in the right place (in the iProperties, not in typing) and make sure every export gets that name automatically, for instance with the export tools in Thundercad. No more guessing in a folder called "final".

What a good file name tells you

A file name is a drawing's business card in every place where your CAD system is not watching: in an inbox, on a USB stick at the supplier, in the customer's download folder. There, the name has to answer three questions: what is it (drawing number), which state is it (revision) and what is it about (description). A name like "30125-C-Side-plate-lower-frame.pdf" does exactly that.

Everything else is noise. A date in the name goes stale at the first change. Words like "new", "final" or "copy" only describe the moment of saving, and the drafter's initials belong in the title block. The less a name contains, the longer it stays correct.

There is a second gain: sorting and searching. With the number up front, all issues of the same drawing line up neatly in the export folder, and the work planner who searches for "30125" finds everything belonging to that part in one go. Anyone who has ever dug through a folder with three hundred "final" PDFs knows how much that is worth.

Choosing a convention that keeps working

A convention does not have to be pretty, it has to be unambiguous. These five rules cover most drawing offices:

• one fixed order: number first, then revision, then description;
• one separator, the hyphen for example, and no spaces or characters that trip up other systems;
• a number block of fixed length, so sorting in the file explorer works;
• the revision always included, even on the first issue;
• a short description in consistent wording, without "final" or "new".

Record where each block comes from. That sounds formal, but it is a three-line table:

Decide consciously which language the description uses in the name and keep that the same everywhere; mixed languages in one folder look like two different systems. Appoint one owner who decides edge cases, too, or variants will slowly appear that each "almost" follow the convention.

Why the source belongs in iProperties

Typing the name yourself at export time looks harmless, but it is retyping, and retyping goes wrong. One colleague writes "Side plate", another "side plate LF", and after a rush job the file is suddenly named after the project number. A typed name also goes stale quietly: when revision C becomes revision D in the model, the old export just sits there as if nothing happened.

The solution is the same as for the title block: one source. Drawing number, revision and description already live in the iProperties of your model or drawing; your title block reads them there, your BOM reads them there, so let your file names read them there too. Change a field and the rest follows. The precondition is that those fields are filled and consistent: the iProperty Panel in Thundercad shows a configurable data card per document type for exactly that, keeping the agreed fields in view at all times. How to get and keep iProperties in shape more broadly is something we covered earlier in Managing iProperties in Inventor without chaos.

Exports that carry their own name

With the convention on paper and the iProperties filled, the last step is automating the application. Batch Publish exports drawings in bulk to PDF, DWG, DXF and STEP and builds the file name from the iProperties while doing so, following the pattern you configured. One run produces a complete drawing package in which every file is named identically, no matter who pressed the button, and it works together with Vault as well.

That also removes the renaming round afterwards, exactly the step that is dropped first under time pressure. The export of a rush job gets the same tidy name as one from a quiet Tuesday morning. Where all those neatly named files should land is the other half of the story; for that we wrote An export folder structure everyone understands.

Rolling it out without wrecking your archive

The biggest mistake with a new convention is trying to clean up retroactively. Renaming source files breaks references between assemblies, drawings and parts; never do that loose in the file explorer. So leave the archive alone and apply the convention from now on: new projects follow the rules, old projects follow automatically at their next revision.

If a customer demands their own naming, for instance with a project code up front, create a separate export pattern for them instead of rebuilding your internal convention. Internally everything stays on number-revision-description; only what leaves the building for that customer gets their format. That keeps your own archive predictable.

The rollout needs no more than one page of documentation and a check at release. After a few weeks the number-revision-description pattern becomes so familiar that any deviating name stands out immediately, and that is exactly the point.

Frequently asked questions

Does the description really belong in the file name?

Strictly, number plus revision is enough; that combination is unique. The description is there for everyone without access to your systems: the shop floor, the supplier, the customer. For them, "30125-C-Side-plate-lower-frame" is the difference between grabbing the right file and having to open it first. Do keep it short.

What do I do with thousands of existing files?

Nothing, and that is a serious answer. Renaming retroactively costs days and breaks references in your CAD environment. Apply the convention to everything issued from now on; within a few months, everything that actively matters has moved over by itself.

Does this work for STEP and DXF going to suppliers too?

Especially there. A supplier only sees file names, no iProperties, so the name is their only handle on number and revision. With Batch Publish, PDF, DWG, DXF and STEP all get the same generated name; you can simply try it free for a month on your own drawing package.