Revit Template Setup: Keep .RTEs Lean With a Governance Checklist
A Revit template (.RTE) is the repeatable starting environment that locks units, object styles, annotation, view templates, essential families, browser organization and title-block conventions. A practical way to build one is to start from an out-of-the-box template or a blank project, set those standards, purge project-specific content, save as .RTE and add it to the New Project list.
TL;DR:
Set metric or imperial units and discipline defaults before modeling; reversing that choice later is difficult, and shared annotation, line weights, and views need consistency.
Load only families reused across most projects, such as doors, windows, tags, and symbols; keep larger or optional content in a central library.
Before publishing, create a fresh test model and check schedules, title block fields, warnings, view behavior, and printed line weights; opening successfully is not enough.
Keep real site data and project links out of the template; use a neutral location, leave base points at the origin, and set coordinates before linking.
For live projects, transfer selected standards one category at a time; this copies settings but does not replace the template or remove old family types.
Table of Contents
What belongs in a Revit template: the audit checklist
Use this list to audit an existing template or to plan a new one. Autodesk describes a Revit project template as a starting environment rather than a finished project, so the checklist below covers decisions that should be identical on every job.
Units and discipline defaults: set metric or imperial, plus discipline settings, before anything else.
Object styles and line weights: a minimal set with clear names.
Annotation styles: text, dimension and tag types locked in.
View templates, filters and view scales: standardized by purpose.
Title blocks, sheet conventions and standard schedules: precreated so new projects can document on day one.
Essential families only: keep the rest in a central library.
Project Browser structure: consistent prefixes and a logical view and sheet organization.
If a setting does not recur across most of your projects, it probably does not belong here.
How do you create and save a Revit project template?
Autodesk documents the workflow in its guide to creating a project template. Here is the sequence:
Open the New Project dialog from Home > Models > New, or File > New > Project.
Under Template file, choose None, or browse to an existing template if you are adapting one.
Under Create new, select Project template. If you started from None, specify the initial units when prompted.
Define your settings, then add view templates, title blocks, schedules and any optional base geometry you plan to reuse.
Choose File > Save as > Template and save the .RTE file.
Add the file to your templates folder or to the template list in Options > File Locations so it appears in the New Project dialog.
Autodesk notes the default template directory varies by installation; its Revit 2026-page lists %ALLUSERSPROFILE%\Autodesk\RVT 2026\Templates.
Standards to define inside the template
Standards are where a template earns its value, because every view, sheet and tag downstream inherits them.
Units and discipline defaults: metric versus imperial is the earliest decision and the most painful to reverse. Settle it, along with rounding and discipline settings, before anyone draws a wall.
Object styles and line weights: keep a minimal set, name items consistently, and set values once so every project prints with the same hierarchy of lines.
Annotation styles: standardize text, dimension and tag types, and define the shared project parameters your title blocks read from. Our guide to Revit project information covers that side.
View templates and filters: create named view templates for working, coordination, presentation and documentation. When you apply several filters, their order determines priority, so test the stack. Autodesk’s page on view filters explains how to apply them through view templates, and this walkthrough on view templates suggests deciding explicitly which properties users may override.
Pro Tip: Enforce graphics through view templates and filters instead of loading extra families, and our view template guide shows a practical way to do it.
Families and content strategy: what to load and what to leave out
A good template is deliberately smaller than a content library. A practitioner-oriented view template article makes the same point: favor a minimal template over loading every potentially useful family, since bloat slows startup and adds maintenance. Autodesk’s guidance on how to model efficiently also warns against populating templates with excessive families.
Load only what most projects reuse: doors, windows, tags and annotation symbols you place constantly.
Keep optional and large families in a central library and load them on demand.
Name and version families carefully. Reloading a family can overwrite existing types or create additional ones when names differ, so a renamed type quietly becomes a duplicate.
Clean before publishing with Purge Unused or Project Browser selection, as described in Autodesk’s page on working with families.
Pro Tip: Treat a family rename like a database migration: rename in the library, reload everywhere and purge, rather than renaming types inside live projects.
Views, sheets and Project Browser organization
New projects feel fast when documentation structure already exists. Build these conventions into the template so nobody invents them on the fly.
Named view templates for working, coordination, presentation and documentation views.
Master sheets with empty views placed, so every project inherits a documentation skeleton. Our sheet setup checklist and title block guide go deeper.
Consistent prefixes for view and sheet names, matched to a Project Browser organization that sorts logically. Our explainer on the Project Browser shows how.
Numbering rules for views and sheets, agreed early, so numbers do not collide when a second discipline joins.
Autodesk’s educational unit on how to create a project notes that saving a model as a template lets you reuse a construction documentation set, with views on sheets updating as geometry is added.
Base geometry: when levels, grids or model elements belong in a template
Autodesk’s workflow allows a template to start from a project containing reusable base geometry, but that does not mean it should. Include geometry only when it clearly saves time across most projects, such as repeated building types or a recurring campus layout.
Avoid embedding project-specific levels and grids. They create relationships that cost time to untangle later, and Autodesk’s efficiency guidance flags walls spanning many levels as a source of update complications.
If you do include geometry, test it. Check the coordinate origin, confirm the levels behave with your view templates, and make sure schedules pick up the elements correctly. A template that seeds a model with the wrong elevations is worse than an empty one.
Cleaning, testing and distributing the template
Before publishing, follow a short release routine. The checklist from IMAGINiT on purging a template built from an existing project is a good reference.
Run Purge Unused, clean up the Project Browser, and delete project-specific links and geometry.
Inspect warnings and resolve them.
Create a fresh test model from the template and verify views, schedules, title block fields and print output.
Save a clean master copy and version it separately from active project files.
Place the .RTE in a shared templates folder or add it to each user’s New Project list.
Be sure to complete step 3. A template that opens fine can still print with the wrong line weights or leave a title block field blank.
Maintenance and governance: naming, updates and Transfer Project Standards
Light governance keeps a template from decaying into a dumping ground.
Assign one template owner and a simple versioning policy for updates.
Use one naming scheme with consistent prefixes for families, views and sheets. Autodesk forum guidance on family standards shows why stable names prevent silent duplication on reload.
Update the master template for new projects. For live projects, use Manage > Transfer Project Standards. Autodesk’s documentation lists transferable categories such as view templates, object styles, annotation styles, line weights and fill patterns, and asks you to choose Overwrite or New Only when duplicates appear.
Remember the limit: Transfer Project Standards copies selected standards but does not replace a template, and reloading families does not remove old types.
Pro Tip: Open both files, transfer one category at a time, and check the results before moving on. Bulk transfers make it hard to see what changed. The Transfer Project Standards steps are short enough to keep on a checklist.
Preloading and managing linked files in templates
Linked files are the item most often forgotten when a template is built from an old project. A link to last year’s survey or consultant model carries project-specific geometry, coordinates and warnings into every new job, which is why the purge checklist above includes deleting project-specific links.
The safer default is a template with no links loaded. Instead, document the linking routine your office follows: which discipline models get linked, the positioning option you use (origin to origin, shared coordinates or project base point), and where link-specific view templates live. That keeps the template clean while still standardizing behavior.
If you want to preload anything, preload the controls rather than the content. Pre-build view templates and filters for linked-model visibility, such as a coordination view that grays out a linked structural model, so the graphics are ready the moment a link arrives. Create those in the template and test them against a sample link in your test model.
Finally, decide how links are reported. Many offices add a short schedule or note on a coordination sheet listing each link and its version. Adding that sheet to the template costs nothing and gives the team a single place to confirm that everyone is working against the same background models.
Configuring worksharing settings and default worksets in templates
If your projects are collaborative, worksharing choices belong in the template planning, because workset structure is much easier to agree on once than to repair mid-project. Our Worksharing Course is built around this kind of collaboration workflow.
A practical approach is to define a standard workset scheme and keep it consistent. Typical offices separate worksets by purpose: shared levels and grids, architectural shell, interiors, links and so on. Decide your names, then write them down so each new project starts the same way.
Think about what actually carries over. Enabling worksharing and creating worksets are project-level actions, so many teams treat the template as a place for the standard, plus view templates and filters that make workset-based visibility easy to apply. Check what your own template does after you create a test model: confirm which worksets appear, who owns what, and how new elements are assigned.
Keep the workset list short. A long list invites misplaced elements and confusing visibility. Name worksets with a consistent prefix, assign levels, grids and links to their own worksets, and review the structure whenever the template version changes. Document the open, synchronize and relinquish routine alongside the template so new team members follow the same habits from the first day.
Project Location and Project Base Point default settings
Location and base point settings determine how a model relates to the real world and to other disciplines’ models, so they deserve a deliberate default in your template.
Start with the principle: the template should not carry a real site location. A leftover address, latitude or survey coordinate from a previous job quietly feeds sun studies, energy settings and link positioning in the next one. Set a neutral placeholder location that your team knows to replace, and add a reminder to your new-project checklist.
Treat the Project Base Point and Survey Point the same way. Leave both at the origin in the template, and note your office rule for when and how they move. Moving them after links are in place can shift the relationships between models, so agree on the sequence: set location and coordinates first, then link, then model.
Decide your link positioning standard in advance. Whether your office uses origin to origin or shared coordinates, record it in the template notes so every project starts from the same assumption. Test this when you create your sample model: open a link, position it your standard way, and confirm the base point behaves as expected. Related reading on the project parameters that travel with your title block is in our project information guide.
Template update and version control strategy
A template is a living document, and version control is what keeps it trustworthy. Without it, three offices end up with three different “current” templates.
Start with a naming convention that carries the version and Revit release, for example a template name followed by a version number and the Revit year. Keep one master copy in a protected location, accessible read-only to everyone except the template owner. The IMAGINiT checklist referenced earlier advises keeping a clean master copy versioned separately from active project files, and that applies here.
Keep a simple changelog. Each entry should record the date, who changed it, what changed and why. A short log saves hours when someone asks why a line weight changed or a filter disappeared.
Decide how updates reach live projects. For new projects, select the template you want to use. Existing projects should only receive changes through Transfer Project Standards, and only when the project team agrees. Test every new Revit release against your template before upgrading it, including print output and schedules, and keep the previous version available until the new one passes. A short smoke test, covered earlier, applies to every release.
Keep it small, test it often
The strongest templates I have seen are the smallest ones. Resist the urge to load every family you might need; enforce graphics through view templates and filters, and let the library carry the rest. After every update, run a short smoke test: create a fresh model, place a few elements, print a sheet and scan the warnings. Keep a changelog beside the template. Small governance habits like these prevent the long, costly cleanup that follows a template nobody owns.
— Steve
Learn template setup in a guided Revit course
If you would rather build your template alongside a trainer than piece it together from documentation, our Revit training is project-based. Start with our Revit Course Only at €79, one time, with lifetime access to the materials.
Revit Course Only: core Revit training
Worksharing Course: collaboration workflows for teams adopting shared templates
Advanced Course: advanced Revit training
FAQ
What is a Revit template?
A Revit template is an .RTE file that gives every new project the same starting settings, including units, line styles, view templates and loaded families. A normal project is saved as an .RVT file, per Autodesk’s template overview.
How do I insert a template into a new project?
Open the New Project dialog from Home > Models > New or File > New > Project, then pick your template from the list or browse to the .RTE file. If it does not appear, add it to your template list, as described in Autodesk’s LT template documentation.
How do I apply a template to an existing Revit project?
To apply standards to an existing project, open both files and use Manage > Transfer Project Standards to copy the categories you want, choosing Overwrite or New Only when duplicates appear.
What is the difference between a Revit project file and a template file?
A project file (.RVT) holds a specific building model, while a template file (.RTE) holds the reusable setup that new projects start from. Think of the template as the repeatable environment and the project as the actual work.
Sources
Recommended
Comments