Your Revit View Template Library Is a Junk Drawer. Here's the Shape.

A typical multi-discipline project accumulates forty to eighty View Templates over its lifecycle. That range is what we see auditing real projects - architectural, structural, MEP, and interiors all contributing, plus a few templates per phase. By the middle of Construction Documents, nobody on the team can tell you which templates are still in use. Nobody can tell you which sibling templates silently disagree. Nobody can tell you which filter references point at rules deleted six months ago. The templates still work. The sheets still issue. The drift is invisible until it is not.

Revit's template tooling is the reason. The Edit View Template dialog shows one template at a time. It does not diff, audit, or bulk rename. At forty templates, this is inconvenient. At eighty, across four disciplines and three phases, it is unmanageable. The fix is not a better editor. The fix is a shape - a hierarchy, a naming pattern, and a recurring audit that treats drift as a maintenance tax.

Template drift is the third of five dimensions in Revit model health; the pillar guide places it alongside warnings, parameter integrity, worksharing, and sync performance.

Templates Fail Quietly

A bad template strategy does not announce itself. The view prints. The sheet issues. Nobody files a bug. The failure shows up in a coordination meeting when the architect's plan and the structural plan look like they are showing different buildings. Or it shows up in a QA check two weeks before issue. Someone notices that the demo plan and the new construction plan share a phasing filter that nobody remembers assigning.

Three silent failure modes do most of the damage.

Unexplained divergence between sibling templates. Two floor plan templates that should behave the same way have drifted over the course of the project. Someone duplicated one, changed three parameters to fix a view, and nobody noticed the copy stopped matching. Six months later the templates control different subsets of the model.

Filters attached to individual views. A user hit a one-off problem, created a filter, assigned it to their view, and moved on. The filter is now invisible to anyone managing templates at scale. The next person who edits the template will not see it. The next person who copies the view will not inherit it. It is a local fix that nobody can find.

Orphaned filter references. A filter was deleted from the project but the templates still reference it. The reference does nothing, but it clutters the audit and makes the remaining filters harder to reason about.

The root cause of all three is the same. Revit's template UI is a single-record editor. You cannot see all sixty templates at once. You cannot compare two of them side by side. You cannot rename in bulk. Without those affordances, drift is the default state.

A Three-Tier Hierarchy

A Revit view template strategy is a three-tier hierarchy (base, purpose, sheet), a discipline-prefixed naming pattern that sorts itself in the dialog, and a monthly audit cadence that keeps multi-discipline Revit view templates from drifting silently. Every template in the project should land in one of the tiers, and the rules for what lives in each tier are strict.

Base templates define the common settings for a discipline and view type. One base template per pair. A - Floor Plan - Working is the default architectural plan. S - Floor Plan - Working is the default structural plan. The base controls scale, detail level, model category visibility, annotation category visibility, and V/G overrides. Every view in its discipline and view type starts from the base.

Purpose templates specialize the base for a specific deliverable. They are created by duplicating the base and modifying only what changes for the deliverable. A - Floor Plan - Presentation [CD] adds rendering overrides. A - Floor Plan - Demo turns on phasing filters and hides new construction. S - Floor Plan - Foundation hides upper structure.

The drift test for a purpose template is a single question. How many parameters does it override relative to the base? If the answer is most of them, it is not a purpose template. It is a fork that happened to inherit the name. A purpose template that controls more parameters than the base is a sign that someone modified the copy to fix a view-level problem and never rebased.

Sheet templates configure views for final sheet production. Title block formatting, sheet-specific scale adjustments, print-only overrides. This tier is optional. Most firms should skip it and handle sheet-specific settings at the view level rather than spawning another class of template. If you find yourself with more than a handful of sheet templates, something at the purpose tier is probably underspecified.

A Naming Convention That Sorts Itself

The pattern is {Discipline} - {ViewType} - {Purpose} [{Phase}]. Single-letter discipline prefix, hyphen-separated segments, phase suffix in brackets when it matters.

Examples from a real multi-discipline project:

A - Floor Plan - Working
A - Floor Plan - Presentation [CD]
S - Floor Plan - Framing
M - Floor Plan - Piping
E - Floor Plan - Lighting
I - RCP - Finish Ceiling
A - Section - Wall Detail

The order is not cosmetic. Revit sorts the template dialog alphabetically by name, and that sort is the one UI surface you cannot change. Discipline first groups the dialog by team. ViewType second groups by workflow within each team. Purpose third distinguishes deliverables within a workflow. A BIM Manager scrolling the dialog reads it like a table of contents instead of a junk drawer.

The rules that make the sort work:

• Single-letter discipline prefix (A, S, M, E, I, L)
• Hyphens between segments, with spaces around the hyphens
• No spaces inside the prefix (A - not A -)
• Phase suffix in square brackets at the end, only when a template has phase variants

This is a convention, not a religion. Teams that already have a working pattern should keep it. The article's argument is about the shape of the hierarchy, not the specific letters. What matters is that the convention produces a sort order that matches how the team thinks about the work.

Where Filters Belong

Filters are the second half of the template equation. Templates control which categories are visible. Filters control how specific elements within those categories appear. In a multi-discipline project, filters are where template strategy usually breaks.

Three rules, in order.

Shared filters go on the base template. A filter that applies to every architectural plan belongs on A - Floor Plan - Working, not copied into every plan template separately. If the base owns the filter, every purpose template inherits it. If the filter lives on each purpose template, updating it later means editing each template by hand.

Purpose-specific filters go on purpose templates. A filter that only matters on demolition plans belongs on the demo template. Assigning it to the base instead will apply it to every architectural plan in the project, which is almost never what anyone wanted.

Never assign filters to individual views. This is the rule that gets broken most often and causes the most damage. A view-level filter is invisible to anyone managing templates at scale. It does not show up in a template audit. It does not copy when someone duplicates the view. It is a local patch that quietly accumulates until a coordination meeting surfaces it. A common scenario: an MEP engineer adds a pipe-color filter to a single view during a review. The view gets duplicated twice for the next two phases. Two years later, nobody can explain why three plans color pipes differently than the rest of the set. If you need a one-off filter, the correct answer is a new purpose template, not a view-level override.

Document the filter-to-template mapping. Pyvoid's Find Used View Templates Filters generates this mapping automatically. A printed version of the map belongs in the project's BIM Execution Plan so that the next person who opens the model knows where the filters live.

The Monthly Audit

Drift is not a one-time cleanup. It is a standing maintenance tax. Treat it the way a software team treats branch pruning - regular, scheduled, unexciting - and the discipline becomes part of the BIM governance loop rather than a weekend rescue. The cadence that works is monthly.

Four checks, run together.

Unused templates. Any template with zero view assignments. These accumulate because views get deleted, templates get forked, or a deliverable got cut from the project. Unused templates clutter the dialog and make the rest of the library harder to reason about. Purge them.

Orphaned filter references. Filters assigned to templates that no longer exist in the project. The references do nothing, but they hide actual filter coverage in any audit report. Clean them out.

Naming violations. Templates that do not match the convention. Most of these are legacy from before the convention existed, or were created quickly during a fire drill and never renamed. A bulk rename run against the convention rules catches them in one pass.

Incomplete templates. Purpose templates that are missing overrides relative to the base. Usually a sign that a template was duplicated, partially modified, and left in an inconsistent state. These are where silent divergence hides.

Pyvoid's Template Audit tool runs all four checks on a project and produces a ranked list. Template Diff shows exactly where two sibling templates disagree, parameter by parameter. Meta View Template Manager is a Pyvoid tool that diffs, audits, and bulk-edits Revit View Templates across an entire project for BIM Managers maintaining multi-discipline libraries. It gives you a dashboard view of every template with filter counts and usage stats, plus bulk rename and filter copy across templates. The audit is the forcing function. Without it, even a well-designed hierarchy decays into a junk drawer within two projects.

Multi-Office Is a Different Problem

Single-office template governance is a discipline problem. Multi-office is a version control problem. The pattern that works treats it that way - and it pairs with worksharing best practices when teams collaborate across firms.

Maintain a single master template file. Each office pulls templates from this file using Transfer Manager. The master is the source of truth. Office copies are working copies. Drift between them is expected and needs to be reconciled, not ignored.

Three practices keep the master honest.

Sync groups. Mark which templates must stay identical across offices. A sync group is a contract: these templates are not allowed to drift. Any office change to a sync-group template is a change to the master, or it gets reverted.

Audit after every transfer. After an office pulls from the master, run Template Audit against the received templates. Transfers fail silently all the time - a filter did not come across, a parameter did not update, a template name collided and got renamed. Without the post-transfer audit, a year later you have N forks of the master and no record of which diverged when.

Version the master. Store date-stamped copies of the master in a shared location. When an office asks what changed in the last sync, you want a diff, not a memory.

Frequently Asked Questions

How many Revit View Templates should a project have?

A typical multi-discipline project accumulates forty to eighty View Templates by Construction Documents. Past eighty, you're paying a cognitive tax for no additional control. If your library is over that range, run an audit and look for duplicates, orphans, and zero-view templates.

What is the best naming convention for Revit View Templates?

{Discipline} - {ViewType} - {Purpose} [{Phase}]. Single-letter discipline prefix (A, S, M, E, I, L). Hyphens between segments with spaces around them. Phase suffix in square brackets when the template has phase variants. Order matters because Revit sorts the template dialog alphabetically.

Should View Template filters be on templates or individual views?

Filters belong on templates, never on individual views. Shared filters go on the base template. Purpose-specific filters go on the purpose template. View-level filters are invisible to anyone managing templates at scale - they don't show up in audits or copy when views are duplicated.

How do I find unused Revit View Templates?

Run a template audit that checks for zero view assignments. Pyvoid's Template Audit runs four checks together: unused templates, orphaned filter references, naming violations, and incomplete templates. Without the audit, even a well-designed hierarchy decays into a junk drawer within two projects.

What is the difference between a base View Template and a purpose template?

The base template defines common settings for a discipline and view type: scale, detail level, model and annotation category visibility, V/G overrides. The purpose template specializes the base for a specific deliverable. The drift test: if a purpose template overrides most base parameters, it's a fork.

How often should a multi-discipline View Template library be audited?

A multi-discipline View Template library should be audited monthly during active production. Four checks together. For multi-office projects, audit after every transfer from the master file. Without the post-transfer check, you end up with N forks of the master and no record of which diverged when.

The Shape Is the Product

The template problem is not too many templates. It is no shape. A three-tier hierarchy, a naming convention that sorts itself, filter rules that match the hierarchy, and a monthly audit will outlast any individual on the project. None of this requires Pyvoid. The strategy works at a firm with zero Pyvoid seats; it works faster with tools that make the audit cheap.

The takeaway for next Monday: open your project's template dialog, sort by name, and count how many templates have zero assigned views. That number is the drift your library is carrying. Start there. For more on how surface design shapes which audits actually get run, see The Revit Ribbon Is Just One Surface.