A Revit view template strategy that keeps sheets consistent

What view templates actually do

A view template is a saved set of view properties: scale, detail level, visibility and graphic overrides, filters, view range, phase settings, discipline and more. You can use a template in two ways:

• Apply once. The template's settings are copied into the view, which can then be changed freely.
• Assign. The view stays linked to the template. Properties the template controls are locked in the view and update whenever the template changes.

Assignment is what makes templates powerful. Change a filter color in one template and every assigned view follows. It is also what makes careless template edits dangerous, because one change can alter every sheet in a set.

Each template property has an include setting. Included properties are controlled by the template; excluded ones are left for each view to set. Choosing what to include is the core of a template strategy.

Principles

1. Templates represent drawing types, not individual views. "General arrangement plan, 1:100" is a template; "Level 2 plan for the client meeting" is not.
2. Assign templates to sheet views. Views that appear on issued sheets should be controlled; working views can be freer.
3. Include what must be consistent, exclude what must vary. Graphic overrides and filters usually belong in the template. View range and crop often vary per view and may be better excluded.
4. Fewer, well-named templates beat many specialized ones. Each template is something to maintain.
5. Someone owns them. Template edits on live projects should follow a simple change rule.

How many templates do you need?

Start by listing the drawing types your firm actually issues, by discipline and scale. A small architectural practice might need something like:

Multiply by scale only where graphic settings genuinely differ. Annotation scales automatically in Revit, so a separate template per scale is not always needed.

What to include and exclude

There is no universal answer, but a common pattern is:

• Usually included: visibility and graphic overrides for model and annotation categories, filters, detail level, model display, shadows and lighting, phase filter, discipline, and visibility of linked models where links are consistent across projects.
• Often excluded: view range for plans, since levels vary; crop region settings; and scale, where one template serves several scales.
• Decide deliberately: phase, because a renovation project's templates may differ from a new-build's; and workset visibility, which depends on how each project is set up.

Write down the reason for each excluded property. The next person to maintain the template will otherwise "fix" it by including it.

Use filters for meaning

Filters let templates express meaning, not just appearance. Rule-based filters can show existing, new and demolished elements differently, highlight fire-rated walls or grey out elements in a linked model. Because filters live in the template, the same visual language applies across every assigned view.

• Base filters on stable parameters, such as type parameters set by the template's standard types, rather than on names that might change.
• Name filters by what they show, for example "Walls - Fire rated 60".
• Keep a short list of firm-standard filters in the project template, and avoid filters that only one project uses.
• Check filter order, because overlapping filters take priority from the top of the list.

Set defaults for new views

Each view type can specify a template that is applied to new views of that type. Setting these defaults in your project template means that new floor plans, sections or drafting views start with the right graphics, without relying on everyone remembering to assign a template. Combine this with clearly named view types, such as a separate view type for working plans, so that people choose the right starting point.

Naming templates

Template names should sort by discipline and drawing type, and include the scale only where the template is scale-specific:

A-Plan-General Arrangement
A-Plan-Reflected Ceiling
A-Section-Wall 1:20
A-Detail-Drafting
A-3D-Presentation
A-Working-Plan

A clear naming pattern also makes it easy to spot templates that do not belong, such as those imported accidentally from another project. See the naming conventions guide for general rules.

Governance on live projects

Most template problems happen on live projects: someone changes a template to fix one view and unknowingly alters forty sheets. Simple rules prevent this:

• Only named people edit templates on a live project.
• Before editing, check how many views use the template.
• If one view needs something different, duplicate the template with a clear name rather than editing the shared one, or exclude that property for the view.
• Use temporary view properties to experiment without changing the template.
• Record template changes in the project's issue log before an issue.

At the firm level, maintain templates in the project template file, test changes on a sample project before release and publish a short change note each time.

Transferring and updating templates

Revit can transfer view templates between projects. This is useful for updating a live project with improved templates, but it can also overwrite local adjustments or bring in duplicate filters and types. Test transfers on a copy first, and compare the before-and-after appearance of a few sheets. It is worth keeping a "template test" sheet set in the project template that shows each template on representative content, so changes are easy to review visually.

Testing template changes safely

Because one edit can change many sheets, test view template changes before they reach live projects. Keep a small test project that contains representative views: a floor plan, a reflected ceiling plan, a section, an elevation, a detail and a drafting view, each with typical content. Apply the changed template, print or export the affected sheets, and compare them with the previous version. Look particularly at line weights, hidden categories and filter results, which are easy to miss on screen.

When a change is approved, record it in the template change log with the date and reason. If a live project needs the change mid-stage, transfer only the affected template, check a few sheets, and let the project team know what changed.

Common mistakes

• Templates per view. Dozens of near-identical templates that differ in one setting.
• Everything included. View range and crop locked by a template, forcing duplicates for each level.
• Overrides in views instead of templates. Manual element overrides do not follow the standard and are hard to audit.
• Imported clutter. Templates and filters copied in from consultants' or old projects.
• No owner. Changes made under deadline pressure without anyone checking the effect.

How templates relate to the rest of your standard

View templates sit on top of object styles, line styles and line weights. If those foundations are inconsistent, templates cannot fix them. The same applies to content migrated from CAD: details converted into native drafting views should use your template's line styles, text types and filled region types so that drafting-view templates display them consistently. The layer mapping guide explains how to make that happen during migration, and the small firm standards guide describes the foundation layers in order.

View template checklist

• List of drawing types and scales the firm issues.
• One template per distinct drawing type, named by discipline and type.
• Include settings decided and reasons recorded.
• Firm-standard filters based on stable parameters.
• Defaults set for new views by view type.
• Sheet views assigned; working views separated.
• Edit rights and change notes for live projects.
• Template test sheet set for reviewing changes.