EngineeringMechanical EngineeringStandards
SOLIDWORKS Templates, Sheet Formats & Custom Properties
Every document the engineering function issues begins as a copy of a template. Whatever is wrong in the template is wrong in everything downstream — and of the three artefacts that carry the standard, the property schema is the one that must be right before the first document is ever created.
- Group · Standards
- Series · Administration
- Baseline · SOLIDWORKS 2026
- Reading · 18 min
01 The Highest-Leverage Standard
Every document the engineering function issues begins as a copy of a template. Whatever is wrong in the template is wrong in everything downstream, and correcting it retrospectively means touching every file already created.
Three artefacts carry the standard. Templates supply document settings — units, drafting standard, dimension behaviour, and the property schema. Sheet formats supply the drawing frame, title block and the links that populate it. Custom properties supply the data that flows into title blocks, bills of materials, vault data cards and downstream business systems.
Of the three, the property schema is the one that must be right before the first document is created. Units can be changed; a title block can be revised; a property renamed after two thousand parts exist requires every one of them to be touched. This asymmetry should drive how much effort goes in up front.
File extensions, property linking syntax and the tools described here are stable across releases, but menu locations and specific capabilities do change. Verify interface paths against the documentation for the release in service.
02 The Template Set
What a template carries
A template is a document saved with settings but no geometry. Everything in document properties travels with it — units and precision, drafting standard, dimension and annotation behaviour, image quality, plane naming, and any custom properties defined at document level. Anything set in system options does not travel, because those are machine settings rather than document settings.
That distinction is the source of a recurring confusion. An engineer who changes a setting and finds it does not carry to the next document has changed a system option; one who finds it carries to new documents but not to existing ones has changed a template. Knowing which layer a setting lives in is most of template troubleshooting.
| Template | Extension | Typically more than one because |
|---|---|---|
| Part | .prtdot | Different unit systems, or a distinct template for sheet metal or weldment work |
| Assembly | .asmdot | Different unit systems, or a distinct template for large-assembly configuration defaults |
| Drawing | .drwdot | One per sheet size, each referencing the corresponding sheet format |
| Sheet format | .slddrt | One per sheet size, plus variants for different document classes if the title block differs |
Every additional template is another artefact to maintain through every standards change. A set that grows to dozens because each project or product line acquired its own becomes impossible to keep consistent, and the inconsistency then appears in issued documentation.
The test for a new template is whether the difference is a genuine document setting. Differences in content — a different title block entry, a different material — belong in properties or configurations, not in a separate template.
03 Sheet Formats & Drawing Templates
These are distinct artefacts and are routinely confused, which produces drawings whose frames cannot be updated centrally.
A drawing template carries the document settings for a drawing. A sheet format carries the visible frame — border, title block, revision table position, zone markings — and the links that populate the title block from properties. A drawing template references a sheet format; a sheet format can also be applied to an existing drawing independently.
Why the separation matters
- Title block revision. A company address change or a new certification mark is a sheet format change. Where the format is a separate controlled file, existing drawings can be updated to the revised format. Where the frame was drawn into the template, it cannot.
- Sheet size handling. A drawing that gains a second sheet at a different size needs a different format on that sheet, not a different template.
- Consistency across document classes. Where general arrangement, fabrication and assembly drawings share a frame but differ in document settings, one format serves several templates.
A title block entry typed directly onto the sheet format is static text. It cannot be driven from the model, will not update when a property changes, and cannot be extracted by a vault or a downstream system. Every field that carries data — part number, description, material, revision, designer, date, approval — must be an annotation linked to a property.
The recurring symptom of getting this wrong is a drawing whose title block disagrees with the model it documents, discovered after issue.
Property linking
Annotations reference properties through a link syntax. Two scopes exist and the distinction is important: one resolves against the drawing document's own properties, the other against the properties of the model shown in a specified view. Title block fields describing the part being documented use the latter, so the drawing inherits from the model rather than requiring re-entry. Fields describing the drawing itself — drawn by, drawing number where it differs from the part number, sheet revision — use the former.
04 Custom Property Schema
The decision that is cheapest to get right and most expensive to correct. It should be settled before the first template is issued.
Design principles
Naming
- Fix internal names permanently. The name is the key that title blocks, bills of materials, vault data cards and downstream systems bind to. Renaming breaks every binding.
- Use plain, unambiguous names. No spaces where a downstream system may struggle, no abbreviations that require institutional knowledge.
- Match downstream systems. Where an ERP or PLM system expects particular field names, adopt those rather than mapping between two vocabularies.
- Decide document-level versus configuration-specific. Anything varying between configurations — mass, size, part number in a family — must be configuration-specific.
Values
- Use controlled lists wherever the value comes from a known set. Material, finish, document class, approval status. Free text produces variants that break grouping and filtering.
- Link to model data where it exists. Mass, volume and bounding dimensions should be evaluated expressions, not typed values that drift from the geometry.
- Distinguish required from optional. A minimum set must be present before a document can be released; the rest is discretionary.
- Avoid duplicating what the vault holds. Revision and lifecycle state are usually better owned by the data management system than by the file.
A workable minimum set
| Property | Scope | Source | Consumed by |
|---|---|---|---|
| Part number | Configuration | Controlled — entered or allocated | Title block, bill of materials, ERP |
| Description | Configuration | Entered | Title block, bill of materials, purchasing |
| Material | Configuration | Linked to the applied material | Title block, bill of materials, cut lists |
| Finish | Configuration | Controlled list | Title block, manufacturing instruction |
| Mass | Configuration | Evaluated from geometry | Bill of materials, shipping, structural checks |
| Revision | Document or vault | Vault-owned where a vault exists | Title block, revision table, change records |
| Designed by | Document | Entered or captured at creation | Title block |
| Checked / approved by | Document or vault | Vault workflow where one exists | Title block, approval record |
| Document class | Document | Controlled list | Vault workflow routing, filing, search |
A custom property tab can be built to present the schema as a structured form — dropdown lists for controlled values, checkboxes, grouped fields, with required entries marked. This is the practical mechanism that makes a schema actually followed rather than aspirational, because it removes the need for engineers to remember names and permitted values.
Build the tab alongside the schema, deploy it from the same controlled location as the templates, and treat a change to it as a change to the standard.
05 Deployment & File Locations
One authoritative location
Templates, sheet formats and the property tab definition must live in one controlled location referenced identically from every workstation — a network share addressed by UNC path, or a designated vault folder. Local copies are the mechanism by which standards silently diverge, and they arise by default because the installer populates a local template folder.
The file location settings that point at these are system options, which means they are deployed and locked through the settings file in the administrative image. This is the single most important application of the locking policy: a template path left unlocked will drift.
Pointing the file location at the shared path does not remove the locally installed template folder. An engineer browsing to open a template can still reach the local copy, and will if the network is slow or the shared path is briefly unavailable.
Two measures help: set the option that always uses the assigned default templates rather than prompting for a selection, and remove or empty the local template folder as part of the deployment. Neither is sufficient alone.
Access control
- Read-only for users. Engineers need read access; write access belongs to the small group responsible for the standard.
- Vault-managed where a vault exists. Placing templates in a controlled vault folder gives version history and controlled change on the standards themselves, which is worth more than it first appears.
- In backup scope. A template set represents substantial accumulated work and is routinely omitted from backup because it lives on a share nobody thinks of as a system.
06 Change Control
A template change affects every document created afterwards and, in the case of sheet formats, potentially every drawing already issued. It warrants the same discipline as a design change.
- Step 1Record the reasonWhat prompted the change and what problem it resolves. Template changes accumulate over years and the rationale is otherwise lost.
- Step 2Assess downstream impactDoes a property name change break a bill of materials column, a vault data card mapping, or an ERP integration? Property renames are the highest-risk category.
- Step 3Version the outgoing setRetain the previous templates and formats. Where a drawing needs to be reissued years later, matching the format it was issued against matters.
- Step 4Test against real documentsCreate a part, an assembly and a drawing from the revised set and confirm the title block populates, the bill of materials builds, and any vault data card still maps.
- Step 5Decide on retrospective applicationWhether existing drawings are updated to a revised sheet format is a deliberate decision with a cost, not something to leave undefined.
- Step 6Publish and recordNotify the team, and record the change in the standards register with its date and the version superseded.
Adding a property is low-risk. Changing a value is low-risk. Renaming an existing property breaks every title block link, every bill of materials column, every vault data card mapping and every downstream integration that references it — silently, because the links resolve to nothing rather than erroring.
Where a rename is genuinely necessary, treat it as a data migration with a mapping, a script and a verification pass, not as a template edit.
07 Template & Property Checklist
- Schema defined before templates. Property internal names, scopes and controlled value lists settled and documented.
- Single controlled location. Templates, sheet formats and the property tab definition in one place, addressed by UNC path or a vault folder.
- File locations locked. Template, sheet format and property tab paths deployed and locked through the settings file.
- Local defaults neutralised. Assigned default templates always used, and the local template folder removed or emptied.
- Write access restricted. Engineers have read access; a named group holds write access.
- Title blocks fully linked. No typed static text in any field that carries data; model-scoped links used for part data.
- Sheet formats separate. Frames are controlled format files, not geometry drawn into templates.
- Property tab deployed. A structured entry form presents the schema with controlled lists and required fields marked.
- Template set minimal. Each template justified by a genuine document-setting difference, not by project or content variation.
- In backup scope. The controlled location is captured by the backup regime.
- Change control in place. Template changes recorded, impact-assessed, tested against real documents, and the outgoing set retained.
08 Frequently Asked Questions
We already have thousands of parts with an inconsistent property schema. Where do we start?
Not by trying to correct everything. Define the target schema, deploy it in the templates and property tab so all new work is correct from a known date, and stop the divergence growing.
For existing data, prioritise by consumption rather than by volume. Parts that appear in current bills of materials, feed an ERP integration or are actively being reissued are worth correcting; dormant historical parts generally are not. A property update can be applied in bulk through automation where a reliable mapping exists — which is a strong argument for defining the mapping carefully rather than correcting files one at a time.
Should revision live in a file property or in the vault?
Where a data management system is in place, the vault should own it. Revision is a state of the controlled item, and having the vault increment it on a workflow transition guarantees that the recorded revision and the actual approval state cannot diverge. The property in the file is then populated from the vault rather than maintained independently.
Without a vault, the property is the only available mechanism, and the weakness is inherent: nothing prevents it being edited without an approval. That weakness is one of the stronger practical arguments for introducing a vault.
How do we handle drawings issued against an old title block after a format change?
Decide the policy explicitly rather than leaving it to individual judgement. Two positions are defensible. Update all drawings to the current format on their next revision, so the estate converges over time without a bulk exercise. Or update the whole set at once, which is cleaner but means reissuing documents whose content has not changed.
The choice usually turns on whether the change is cosmetic or carries regulatory or contractual significance — a certification mark or a legal entity name generally forces the second, a layout improvement does not. Retain the superseded format either way, so a historical drawing can be reproduced as issued.
Can different teams have different templates?
Where the difference is a genuine document setting — a team working consistently in a different unit system, or to a different drafting standard for a particular customer — yes, and the deployment image supports different file locations per group.
Where the difference is content rather than settings, no. A team wanting a different title block entry, a different default material, or a project code in the frame is describing a property, not a template. Allowing template forks for content differences is how a maintainable set of six becomes an unmaintainable set of forty.
Series context. This page is part of the KEVOS® SOLIDWORKS environment administration series. It presents general administration practice and is written to be release-independent wherever possible. Where specific versions, limits or supported platforms are cited, they reflect the SOLIDWORKS 2026 release family and should be verified against current vendor documentation before being relied upon for procurement, platform or upgrade decisions.
SOLIDWORKS is a registered trademark of Dassault Systèmes SolidWorks Corporation. Product names are used here for identification and reference only. KEVOS® is independent and is not affiliated with, endorsed by, or a reseller for Dassault Systèmes.