Somewhere in the middle of my second year as a CAD administrator I built a folder called Templates that contained 340 part files. Three hundred and forty. I did it with the best intentions — every bracket we used more than twice got its own parametric master, complete with equations and a design table. It felt like progress. Six months later, exactly two people on the team could open those files without breaking them, nobody knew which template was authoritative, and I had created the maintenance burden of seventy-five product lines to save maybe forty hours of modelling. That is the honest story of how most template libraries die. This article is the version I wish someone had handed me before I started.
Before you model anything: decide what deserves a template
The first rule I now enforce is brutal simplicity. A part earns a template only if it is reused in at least three different products AND its geometry changes in a predictable, dimension-driven way. A mounting bracket with a hole pattern that moves as the size changes: yes. A die-cast houside whose cooling fins sprout at odd angles depending on the project: no, that is one-off modelling, and forcing parameters onto it will make the file worse than if you had just redrawn it.
I put a little decision table on the wall, and I still use it before creating anything:
| Reuse pattern | Should it be a template? | Why |
|---|---|---|
| Same part every time, zero variation | No — a library part | A fixed part file with a clear name is simpler than a parameter set |
| Same geometry, dimensions scale predictably | Yes | Parameters earn their keep here |
| Same function, wildly different shapes | No | Forcing one skeleton bends it until it lies |
| Same family, occasional odd member | Yes, with discipline | Model the family, generate the odd one manually |
Honestly, half the template projects I have audited failed because the team parameterized a geometry that was not actually regular. The template itself was fine; the geometry was the liar.
Naming and folder structure beat cleverness
You cannot make a library useful if people cannot find the right template in ten seconds. I use a naming scheme that is boring on purpose: kind_size_metric_function. A template for a flat motor-mount plate becomes PLATE_MTG_MOTOR_200x150_4H or, if we keep it plain, just MOUNT-PLATE_STD. The point is not the aesthetics; the point is that two engineers who have never met can predict the name.
My folder layout looks like this, and it has survived three CAD migrations:
Templates/
Fasteners/ (pins, screws, inserts)
Plates/ (mounting plates, covers, flanges)
Shafts/ (plain, stepped, keyed)
CastParts/
SheetMetal/
Subassemblies/One rule saves more arguing than any document: a template file is read-only reference until someone with the edit permission changes it. Everyone uses templates; one person per family owns them. The day you let the whole team edit the master, you get what I call the “mystery update” — a template that silently changes shape and breaks fifteen assemblies that were already released.
Master sketches beat twenty linked dimensions
Most broken templates I debug have one thing in common: dimensions scattered across eight features, each referencing three others, with no centre of truth. My cure is a single master sketch at the top of the feature tree that carries every drive dimension, and every downstream feature references the master sketch and nothing else. When someone opens the template, they edit the master sketch and the whole part follows. It is stupid simple, and it survives personnel changes better than any tutorial video.
The master sketch holds perhaps six to twelve named dimensions, not forty. If you find yourself driving forty dimensions, your template is really two or three templates wearing one coat. Split it. I keep an internal rule that a template with more than twelve adjustable dimensions is a red flag and deserves a design review before it ships.
Equations and design tables: two tools, two jobs
Equations are for relationships that never change: hole patterns derived from pitch, wall thickness derived from overall size, thread lengths derived from nominal diameter. Design tables are for the rows of catalogue data that do change per member. The clean way to think about it is this: equations encode the logic of your company, design tables encode the catalogue of your suppliers.
Here is an example that comes up in every shop I have visited. A standard mounting plate with four clearance holes, thickness tied to span so it does not warp, and pitch tied to the mating component pitch:
t = pl_H > 250 ? 12 : 8 // plate thickness mm
pitch_X = pl_L / 4 // hole spacing derived
hole_D = 6.6 // M6 clearance, fixed
edge_Dist = 15 // fixed edge marginThen a design table row for each member: length, width, material, mass target. The designer never touches the sketch again — they pick a row, the master sketch updates, drawing updates, done. If that workflow takes more than two minutes, your template has a structural problem, not a user problem.
One technical note that has bitten me more than once: name the master sketch and its key dimensions with a consistent prefix such as ms_ in your CAD tool, because when you export a part or run a drawing script, the parameter names carry over. Nobody remembers what SW-04-021 means six months later, but everyone remembers ms_length.
The checklist I run before a template ships
- Can I open the template, change one master-sketch dimension, and have every dependent feature update without a rebuild error?
- Does every named dimension have a unit and a sensible minimum and maximum?
- Does the model update when the design table switches membership?
- Is the material property pulled from the design table, not hard-coded in three features?
- Did I test the worst-case drive dimension — the biggest and smallest row — not just the middle row?
- Is there a one-page usage note in the folder telling the next person which dimension does what?
That last item sounds soft, but it is the difference between a template people use and a temple people worship from a distance.
Pitfalls I have stepped in so you do not have to
| Pitfall | What it does to your team | My fix |
|---|---|---|
| Over-driving every dimension | Templates too fragile to edit, designers afraid to touch them | Cap at twelve drive dimensions, split the family |
| No single owner per family | Mystery updates, broke assemblies, blame culture | One owner per family, file locked to others |
| Generous names (Plate_ v2_final_REAL) | Nobody knows which file is current | Boring versioned names, template never versioned mid-release |
| No test rows | Only the middle size ever works | Test largest and smallest rows before release |
| Hard-coded materials in features | Mass properties lie, BOM weight wrong | Material lives in the design table only |
| People copy templates instead of using them | Copies drift, library becomes a museum | Make copying a reviewable event, keep the count visible |
How the library survives departures
Here is the uncomfortable reality: your best template modeller will leave eventually. The library survives only if a new hire can understand it from the files and the one-page note alone. That is why I write a short README into every template folder — not a forty-page manual, a single page that says what each family does, which dimension drives what, and which row of the design table not to delete. When a colleague took a job at a competitor two years ago, the department did not miss a release. That is the real metric of a library: it outlasts the people who built it.
Version control is simpler than everyone thinks for templates. Template versions are tied to product releases, not to every tweak. When someone proposes a change to a master, it goes through the same small review as a drawing change — two heads look at it, it gets a new version number, the old version is archived, and the assembly users are told in advance. No silent edits, no v12 that is secretly different from v11.
Closing thoughts from someone who deleted 300 templates
In the end I deleted most of my original 340 and kept maybe twelve families that actually followed the rules. The library became smaller, and the small one is the one people use. Build templates the way you build a good drawing: with clear intent, a single source of truth, and the next person visibly in mind. The parameter is not the point. The predictability is.
If you are just starting, do not build a library. Wait until the same bracket shows up in a third product, then build one template — properly, master sketch first, design table second — and let the pain of the first three multiplications pay for it. That is the anti-fancy advice I wish I had followed.
One template family, told start to finish
Take a motor mount plate, the kind that bolts a standard flange mount motor to a machine frame. The non-negotiable dimensions are the bolt circle, the pilot diameter, and the shaft centre height. The variable dimensions across the family are length, width, the number of fixing holes, and the plate thickness. In my master sketch I publish six names: ms_L, ms_W, ms_T, ms_Bldia, ms_Pilot and ms_Nholes. Everything else on the plate — the corner radii, the slot details, the counterbore depths — is derived or fixed.
Then the design table carries a row per motor frame size, because frame sizes map to shaft heights in a way that is catalogue data, not logic. Row for an 80 frame motor gets one plate geometry, row for a 132 frame gets wider plate and bigger bolt circle, and so on. The designer opens the template, picks the frame row, and the plate updates. Total interaction time is about twenty seconds, and the resulting part is identical in origin and naming across the whole product range — which is worth more than the modelling time, because it is the consistency that makes downstream fixtures, drawings and assemblies all line up.
That last point is the one people miss. A template library is not a collection of files, it is a collection of decisions made once. The second engineer who places that motor mount in an assembly does not re-decide the hole size, the edge distance, or the material — they inherit the decision, and that is the entire value.
What I tell a new colleague on day one
When someone joins my team I give them one sentence about the library: “Templates are decisions, not drawings; change one dimension in the master sketch, and if the feature tree turns red, tell me before you fix it, because red is usually a design conversation, not a modelling race.” That sentence has prevented more bad templates than any rulebook I have written. The red errors are almost always a signal that someone is stretching a template past what it was designed to cover — exactly the moment when you should cut a new template instead of bending the old one.
The other thing I warn about is the temptation to parameterize every last hole. Leave the holes that only appear once alone. A template with one fixed feature that serves one product just to make the model “complete” is dead weight, and dead weight in a template is worse than dead weight in a normal part, because every single user of the library pays for it on every single open.
A final honest trade-off
Templates are a bet that the future will look like the past. Sometimes it does not, and then the template is a liability. The trick is to make that bet cheap — small families, tested rows, one-page notes — so that writing off a template hurts less than writing off a product. Keep the library small enough that every file in it is known, and you will never have to walk a new hire through the museum of a hundred forgotten files. I built the museum once. That is more than enough for me.
