A machine builder gets word from the customer: the project continues under a new order number. To the project manager it is an administrative detail. To engineering it means 140 parts, 30 subassemblies and a folder full of drawings that carry the old number in their iProperties, and therefore on every title block.
Fixing that file by file takes days: open, change the field, save, close, one hundred and forty times without skipping a single one. This is exactly the situation where you want to bulk edit iProperties across an entire assembly: one action that updates the same field in every affected file at once. In this article you will read which fields qualify for a bulk update, how to decide which files take part and how to verify afterwards that everything landed correctly. For the action itself we look at the Assembly iProp Menu from Thundercad, but the reasoning applies to any approach.
One boundary up front: this piece is about the bulk action. Which fields to set up in the first place, what to call them and who fills them is covered in Managing iProperties in Inventor without chaos.
Why file by file is not an option
First, run the numbers on the manual route, with assumptions you can adapt to your own situation. Opening a file, changing the field, saving and closing easily takes a minute including load time. For 140 files that is over two hours of uninterrupted, mind-numbing clicking. And that is for a single field change; if another correction follows next week, the whole exercise starts over.
The real problem is not the time, though, it is the coverage. Manual work across that many files always misses a few: the parts in that one subassembly, the file that happened to be checked out, the drawing nobody had on their radar anymore. The result is insidious: half the title blocks show the new number, the other half the old one, and you only notice once the package reaches the shop floor or the customer. One action with one result is not just faster, it is verifiable.
Which fields qualify for bulk, and which do not
The rule of thumb: anything that describes the project can go in bulk, anything that describes the part cannot. A project number should be identical in every file of the assembly; a description should be anything but.
| Field | Bulk? | Why |
|---|---|---|
| Project number, order number | Yes | Same value for every file in the project |
| Customer field | Yes | Identical across the project |
| Checked by, approved by | Yes | After a checking round you fill the whole set at once |
| Status | With care | Only when the complete selection genuinely gets the same status |
| Description, part number | No | Unique per file; bulk would destroy exactly that |
| Material, mass | No | Physical properties belong to the part itself |
When in doubt, ask the control question: would this value still be correct if the part were reused in another project tomorrow? If not, it is a project field and may go in bulk, but only within the right selection. How to keep that project number identical everywhere, from folder name to title block, is covered in Project and order numbers the same everywhere, from folder to title block.
Decide which files take part
The hardest decision is not the field but the selection. A top-level assembly drags along plenty that does not belong to your project, and that is exactly where bulk editing goes wrong. Walk the structure along these lines:
- The project's own manufactured parts: in. This is the group you are doing it for.
- Reused parts that also sit in other machines: out. Write a project number into those and it shows up on another project's title block tomorrow.
- Standard parts and library components: skip. They should be write-protected, and this is precisely what that protection exists for.
- Files a colleague has checked out in Vault: align first. A bulk edit needs write access; whatever is locked silently keeps the old value.
This is where a tidy project structure pays off: whoever keeps manufactured, purchased and standard parts separated in folders or by library status settles the selection in seconds instead of weighing part by part.
Opening one hundred and forty files to change the same field everywhere is not engineering, it is punishment. With the Assembly iProp Menu from Thundercad you update that field across the whole assembly in a single action.
Try 30 days freeThe bulk edit itself
With the Assembly iProp Menu you adjust the iProperties of a complete assembly in bulk, straight from the open top-level assembly. The routine is the same whatever field you update:
- Open the project's top-level assembly and make sure you have the latest state from Vault or the network.
- Pick the field and the new value, and stick to one field per round: it keeps the verification afterwards unambiguous.
- Set the selection along the lines above: project parts in, reuse and library out.
- Run the edit and save the files.
You do not need to touch the drawings one by one afterwards: a title block that is linked to the iProperties shows the new value as soon as the drawing is opened or updated. If you work with Vault, check the changed set in as one batch, with a single comment line describing the change. That way anyone can later trace when and why the field changed.
Verify that everything landed correctly
A bulk action deserves a bulk check. Verifying file by file would cancel out the time you just won, so check at the same scale you edited at:
- Add a column with the field to the BOM view of the top-level assembly and sort on it. Outliers cluster at the top or bottom and stand out immediately.
- Spot-check the drawings deliberately: one title block high in the structure, one from a part deep inside a subassembly. If those two extremes are correct, the rest almost certainly is too.
- Chase the dropouts. Files that did not take part because they were checked out or write-protected get updated afterwards, or noted explicitly as deliberate exceptions.
Frequently asked questions
Does the change carry through to the drawings automatically?
Yes, as long as the title block pulls the value from the iProperties instead of from manually typed text. The new value appears when the drawing is opened or updated. If an old value lingers somewhere, it is almost always a manually overridden field in the title block.
What about parts that appear in several projects?
Keep them out of the selection. Project-specific information does not belong in a reused part; it belongs in the project's own assembly and drawing. Write a project number into a shared part and that number surfaces in every other project the part hangs in.
Can this be done without extra tooling?
For a handful of files, manual updating is perfectly doable, especially with the BOM view as a check. Once it is dozens or hundreds of files, the risk of missed files outweighs the effort of installing a tool: try the Assembly iProp Menu 30 days free and compare it with your last manual round.