You open a colleague's assembly and you spot it right away: one part has a tidy drawing number in the iProperty field, another has the file name in the title field, and a third has the material partly filled in as "S235" and partly as "steel S235JR". That is not a detail. That is the start of an expensive chain of errors. Managing iProperties in Inventor sounds like paperwork, but in practice it determines whether your bill of materials is correct, whether your PDFs get the right title, and whether your ERP integration works at all.
In this article you will read why inconsistent metadata causes so much pain downstream, how to structure iProperties sensibly, and how to enforce that structure instead of hoping everyone gets it right on their own.
Why managing iProperties in Inventor is more than filling in fields neatly
iProperties are the metadata of your Inventor files: drawing number, description, material, weight, project number, client, revision, status. Inventor has standard fields (such as Title, Part Number, Description, Material) and custom properties that you add yourself. Logical enough. The problem is not in the fields, but in who fills them in and how.
Because those iProperties do not stay inside the model file. They flow through everywhere:
- Drawings automatically pull the drawing number, description and material into the title block through text fields.
- Bills of materials (BOM) read Part Number and Description directly from the iProperties of each part.
- Production documents such as PDF, DWG, DXF and STEP often get a file name or title that is based on iProperties.
- ERP and PDM systems such as Autodesk Vault use these fields to link, search and push files through to purchasing and planning.
A single field that is wrong therefore multiplies throughout the entire chain. A wrong material in the iProperty of a sheet-metal part means a wrong material in the title block, a wrong line in the bill of materials, and a wrong order with the supplier. Not because someone was careless when ordering, but because the source was already wrong.
What inconsistent metadata costs downstream
It creeps in. With a handful of parts you do not notice it. With a machine of 400 components and three engineers who each have their own habits, it becomes a time bomb. A few recognizable situations:
The bill of materials that does not add up
Work preparation exports the BOM to Excel to place orders. Two identical bolts show up as two separate lines because one is called "M8x30 DIN933" and the other "Bolt M8 x 30". Inventor sees them as different items. You order double, or you miss one. Someone has to go through the list manually and deduplicate it, every single time.
The title block that does not fill
The drawing is finished, but the material field in the title block stays empty because the Material iProperty was not filled in on the model. The engineer types it in by hand. Just quickly. Until a revision comes along, the material changes on the model, and the manual text in the drawing stays put. Now the model and the drawing contradict each other.
The Vault search that finds nothing
A colleague searches Vault by project number, but half the files do not show up because the project number was in a different custom field, or was not filled in at all. The file exists, but it is unfindable. Someone starts digging through folders by hand.
Do the math. Suppose an engineer corrects or checks an iProperty field manually ten times a day, and each correction including the context switch costs a minute. That is almost an hour per week per person, just on metadata repair work. With five engineers that is half a working day per week lost to something that could have been prevented at the source.
The insidious part is that this work is invisible. It does not appear on any timesheet as "cleaning up metadata". It disappears into the margins of every drawing, every export, every order. And it undermines trust: if the bill of materials was wrong once, everyone will double-check it from then on. Then you lose the benefit of automation before you ever had it.
How to structure managing iProperties in Inventor
Before you automate anything, you need to know what you want to record. Good metadata starts with agreements, not with tools. A few principles that work well in machine building and steel construction:
1. Decide which fields are mandatory per document type
A part (.ipt) has different relevant fields than an assembly (.iam) or a drawing (.idw/.dwg). For a sheet-metal part you want material, thickness and drawing number; for an assembly you want project number, client and revision. Make a fixed set per document type: what is mandatory, what is optional, and what you should simply not fill in because it is derived automatically.
2. Agree on one notation and write it down
"S235JR" or "steel S235JR"? "M8x30" or "M8 x 30"? It does not matter which you choose, as long as everyone chooses the same one. Record the notation in a short standard and make sure new employees pick it up. The fewer free-text fields where people can come up with something themselves, the more consistent your data.
3. Fill in at the source, not at the end
Filling in metadata at the moment you create the model is cheap. Repairing metadata afterwards across hundreds of files is expensive. Make filling in iProperties part of your standard way of working, not a separate task that you will "get around to later".
4. Use fields that are actually read downstream
There is no point in inventing a custom property "Customer reference" if your drawing title block, your BOM export and your ERP do nothing with it. Match your set of fields to what the chain after it needs. Start at the output (bill of materials, title block, ERP) and work back to which iProperties you have to record for it.
So much for the theory. The hard part is not coming up with this structure, but enforcing it. Because as soon as it depends on manual discipline, it falls apart. People are in a hurry, forget a field, or type it just a little differently. That is where standardization through a tool comes in.
Stop checking and correcting iProperties by hand. With Thundercad's iProperty Menu you fill in metadata in a structured way through one configurable data card per document type, so the source is always correct.
Try it free for 30 daysStandardizing with data cards: the iProperty Menu
The standard iProperties window in Inventor shows all fields jumbled together, regardless of whether you do anything with them. It makes no distinction between "you have to fill this in" and "this happens automatically". And it enforces nothing. Anyone can type anything anywhere.
Thundercad's iProperty Menu turns that around. Instead of a cluttered standard window, you work with one configurable data card per document type. A data card is essentially a form that you set up in advance: which fields you see, in what order, with which labels, and which are mandatory.
Concretely, that means:
- One card per document type. For a part you see the fields that are relevant to a part, for an assembly the fields that apply to it. No noise, no doubt about what belongs where.
- A fixed structure for everyone. Whether a junior or a senior opens the file, they see the same card with the same fields. The agreement you made above now lives in the tool instead of in someone's head.
- Filling in becomes guided instead of invented. Because the card indicates exactly which field is for what, everyone fills in the same thing in the same place. That is exactly what you need to actually hold on to those notation agreements.
The effect lies in the source. If the iProperties go into the model structured and consistent from the start, everything that comes after it is correct. The title block fills itself in correctly. The BOM Export to Excel delivers a list without duplicate lines that you no longer have to deduplicate. Batch Publish saves your PDFs, DWGs and STEP files with the right names. And your Vault or ERP integration receives clean, findable data.
Start small. Set up the data card first for your most common document type, usually the part. Decide which fields are mandatory, record the notation, and roll it out. Once that is running, expand to assemblies and drawings. One good card that everyone uses is worth more than five cards that nobody understands.
Managing iProperties in Inventor: from loose discipline to enforced standard
The benefit of managing iProperties in Inventor is not in nicer fields, but in a chain you can trust. If the metadata is correct at the source, you no longer have to double-check bills of materials, you no longer have to update title blocks by hand, and you can really put tools like Batch Publish and BOM Export on autopilot. That is the difference between "we have a tool that should do it" and "it just happens, every time, correctly".
The iProperty Menu turns an agreement that lives in your engineers' heads into a structure that is fixed in the software. And that is where the real time savings are: not in filling in faster, but in no longer having to correct. Companies such as Little Giant Europe, Van Egten, Banzo and Mannen van Staal already work with Thundercad to take this kind of repetitive work out of their engineering process.
Want to see how it works out for your document types? You can try Thundercad free for 30 days, no credit card required. You can find more background on the individual functions in the knowledge base.
Frequently asked questions
Does the iProperty Menu work together with Autodesk Vault?
Yes. Thundercad works together with Autodesk Vault, and the Dashboard can be linked to your ERP and other software. Because you fill in iProperties consistently through the data card, clean, findable data also ends up in Vault and your ERP.
Do I have to clean up all my existing files first?
No, you do not have to repair everything before you start. The iProperty Menu ensures that new and edited files are filled in in a structured way from now on. You pick up existing files gradually as you work on them anyway. Worth knowing: Thundercad requires Windows 10/11 and Autodesk Inventor 2025 or newer with an active Autodesk account.
What does Thundercad cost?
Thundercad costs EUR 30 per user per month or EUR 300 per user per year (that is two months free), excluding VAT, per seat for 1 to 99 users. You can try it free for 30 days first, without a credit card.