The drawing says S235JR, the model says stainless steel. The title block was typed in on the day the drawing was created; the material changed later, when the customer asked for stainless. Nobody did anything wrong, and yet purchasing is about to order the wrong plate. Whoever fills in the title block by hand will sooner or later fill it in wrong twice: once when creating it, and once by not updating it.
That kind of mismatch only truly disappears when every stamp pulls its value from a single source. In Inventor you can auto fill your title block from iProperties: every text field in the title block looks directly at the model or the drawing. In this article we walk through that data flow: which fields to bind, how to test the template before rolling it out, and what happens the moment the design changes. You fill the source itself faster and more consistently with a toolbox like Thundercad, but the binding works with standard Inventor means.
Typing it twice means two chances to get it wrong
An average title block holds eight to twelve fields: number, description, material, mass, scale, revision, drawn by, checked by, and often project or customer fields on top. For a machine builder creating dozens of drawings per week, filling those in by hand means hundreds of retyping moments per week, and every one of them is a chance for a typo or an outdated value.
The nastiest part is the checking. As long as stamps are filled in by hand, someone has to compare every field against the model at every release: is the material still right, the mass, the revision? That is not design checking but typing checking, and it is exactly the work that gets skipped first under time pressure. That is the gap the wrong plate from the intro falls through.
The data flow: where each stamp gets its value
In the title block definition of your template, you replace static text with text fields bound to a property. As soon as the drawing contains a view of the model, the title block knows where to look: the drawing pulls the values from the model in the placed view, complemented by properties of the drawing and the sheet itself.
The bindings that prove themselves in practice:
- part number and description: from the model's iProperties;
- material and mass: from the physical properties of the part, so a material switch carries through automatically;
- revision: from the revision field you raise in one place when the design changes;
- scale, sheet number and sheet count: from the sheet properties of the drawing;
- drawn by and checked by: from the properties of the drawing;
- customer and project fields: from custom iProperties you define yourself and name identically everywhere.
The rule of thumb: information about the product comes from the model, information about the document comes from the drawing. That way every field has exactly one owner and you never have to guess where to change something.
How to test the template before rolling it out
You do not test a bound title block on a live job, but on a test part you create just for this. Fill every iProperty with a recognisable value, create a drawing from it and walk past every stamp. Then test the edge cases: an extra long description (does it stay inside the frame?), an empty field (does it leave a gap or an error?), a second sheet (are sheet number and sheet count correct?) and every document type you use: part, sheet metal and assembly each behave slightly differently.
The title block is only one part of your template, by the way; frames, styles and defaults deserve the same care. How to approach that as a whole is covered in Drawing templates: set them up right once, benefit for years; here we stick to the data binding.
A title block that fills itself is only as reliable as the iProperties underneath. With Thundercad, engineers fill that source through a fixed data card per document type, with no loose ends.
Try 30 days freeWhat happens when the design changes
The real payoff shows the moment the design changes. The customer wants stainless after all: you change the material in the part, update the drawing, and the title block shows the new value, along with the new mass. No second action, no note for the colleague who owns the drawing. Raise the revision field and every sheet of the drawing shows the same revision. The checking work shifts to where it belongs: the checker judges the design, no longer the typing.
Feel free to work out what that saves. Take as an assumption ten drawings per week and ten bound fields per title block: a hundred fill-in moments and just as many checking moments per week disappear. The numbers differ per company, the direction does not.
There is one condition: the source has to be right. An empty description field in the model now becomes an empty stamp on every drawing. That is why a bound title block comes with a fixed habit of filling iProperties the moment a part is created. The iProperty Panel in Thundercad helps with a configurable data card per document type: the fields your title block needs sit at the top, so a part does not leave the design office with empty stamps. How to keep those iProperties consistent across the department, with naming agreements and mandatory fields, is described in Managing iProperties in Inventor without chaos.
What you deliberately do not bind
Not every field should be filled automatically. "Checked by" is filled at the moment of release, deliberately and by the checker personally; an automatically filled approval field says nothing. Prompted fields that ask for a value when the title block is placed are meant for true exceptions, say a one-off reference for an external party; use them structurally and the manual work sneaks back in through the side door.
The rule that sums it all up: every field has exactly one source. Either the model, or the drawing, or a human at an agreed moment. A field you sometimes bind and sometimes type over is untrustworthy within a month, and then everyone is back to checking everything.
Frequently asked questions
Does this also work for existing drawings?
Yes. If you replace the old title block in an existing drawing with the bound definition, the stamps pull their values straight from the iProperties. Do expect some cleanup on older files whose iProperties were never filled: empty stamps will appear there that you complete once.
What about a customer who demands their own title block?
Create a second title block definition in that customer's style within the same template and bind the same fields. The data stays identical, only the layout differs, and you switch title blocks per drawing without retyping a single value.
How do I prevent empty stamps on new drawings?
Fill the iProperties the moment the part is created, not when the drawing is due. With a fixed data card like the iProperty Panel that takes seconds instead of a search afterwards. Curious how that works out in your own template? You can try it free for 30 days.