After reworking a title block, a CAD admin at a machine builder counted them: 41 custom iProperties in circulation. Nine of those were actually read somewhere, by the title block, an export or the ERP link. The rest had once been created for one customer, one project or one experiment, and never cleaned up afterwards. Three fields had nearly the same name: Remark, Remarks and Remark2.
A list like that is nobody's fault and everybody's problem. Custom iProperties in Inventor take thirty seconds to create and years to get rid of. This article gives you three test questions every new field has to survive, a cleanup method for existing sprawl and the case for one managed field list per document type. The standard fields themselves are not the topic here; this is about the fields you invent yourself. And about how a toolbox like Thundercad helps get the agreed list filled in afterwards.
Why sprawl is nobody's fault
Every custom field starts with a good reason. A customer demands a certificate code on the drawing: add a field. Work preparation wants a note field for the sawing department: add a field. Someone pilots an integration and creates three test fields: never removed. Templates faithfully copy all those fields into every new file, and nobody dares to delete anything, because who knows what still reads it.
After a few years the list has three kinds of residents: fields that genuinely work, duplicates of standard fields (a homemade "Weight" field next to the mass Inventor already tracks) and ghost fields nobody remembers the purpose of. Which standard fields already exist and how to keep them filled consistently is covered in Managing iProperties in Inventor without chaos; tracking the same value twice is almost always the wrong answer.
Three questions every new field has to survive
You do not prevent sprawl with a ban, but with a test. Three questions, and any "no" or "not sure" means the field does not get created:
- Does a system read it? A title block, a BOM export, a search in Vault, the ERP link: something has to demonstrably use the field. "Nice to have around" does not count; if nothing reads it, the field is dead weight.
- Who fills it, and at what moment? A field without an owner and a fixed filling moment stays empty. "The engineer, at release" is an answer; "everyone, a little" means no one.
- Who decides something with it? Behind every field there should be an action: purchasing orders on the supplier code, work preparation plans on the surface treatment. A field nobody acts on is noise that demands weekly maintenance.
Then ask one final control question: does a standard field already cover it? Reusing an existing field almost always beats adding a new variant next to it.
When a custom field does deserve to exist
With that test in hand, plenty of good reasons remain. Three examples from practice:
- Surface treatment on sheet metal parts. "Hot-dip galvanized" or "powder coated" with a color code: the engineer fills it at release, work preparation reads it for outsourcing. System, filler and reader are all named, so the field earns its place.
- Supplier code on purchased parts. Filled by purchasing or by the engineer when the purchased part is created, read by the person ordering and by the BOM export towards the ERP.
- Certificate requirement on load-bearing parts. The design engineer marks which parts need a material certificate; purchasing orders accordingly. One field, one question, one decision.
What these three have in common: they describe the part, not today's process. Fields like "Urgent" or "StillToCheck" do not belong in iProperties; that is a to-do list, and to-do lists age faster than your files.
A tight field list only works when filling it in takes no searching. The iProperty Panel in Thundercad shows a configurable data card per document type with exactly the agreed fields, so engineers fill in everything in one place.
Try 30 days freeCleanup: pruning the existing list
If the sprawl already exists, the same test doubles as a cleanup method. First take stock of every custom field in circulation and note two things per field: what reads it, and how often is it filled? That fill rate is the most honest judge; how to pull numbers like that out of your files is described in How healthy is your CAD data? How to measure your metadata quality.
Then sort the list into four groups: keep (has a reader and a filler), merge (duplicates such as the three Remark variants), retire (nothing reads it) and freeze (doubtful cases: leave them for a few weeks and see who complains). At the very least, remove the retired fields from your templates so new work starts clean; old files do not need retroactive scrubbing, you catch those whenever you edit them anyway. And communicate the new list once, clearly: which fields still exist, and where did the rest go?
One field list per document type
The durable solution is a short, managed list per document type. A part needs different fields than an assembly or a drawing: a surface treatment belongs on a part, a project reference more likely on the assembly. Record per document type which fields exist, who fills them, who reads them and what a valid value looks like. One page per type is enough, with one owner: new fields only enter through that list.
A list like that only stays alive when it is visible inside Inventor. That is where the iProperty Panel helps: the data card per document type is configurable, so the agreed fields sit in front of you in the same order with every file, without digging through tabs. The list on paper and the card on screen are then the same thing, which is exactly the point.
Frequently asked questions
How many custom iProperties are normal?
There is no magic number, but teams that test strictly rarely end up above ten to fifteen per document type. Beyond twenty, the card gets crowded and the fill rate drops by itself. The yardstick is not the count, but whether every field has a named filler and reader.
Can I just delete a redundant field?
First check what reads it: title blocks, templates, exports and integrations can quietly depend on it. Then remove it from the templates so new files start clean. You do not have to rework every existing file; clean those up whenever you touch them anyway.
How do I keep the sprawl from coming back?
One owner for the field list, every new field past the three test questions, and filling in made as easy as possible. With the iProperty Panel you put the agreed fields on screen as a data card; you can try it along with the rest of Thundercad free for 30 days.