Handing your Revit template to an outside production team

Why the handoff decides the first issue

A production team that works in your model and on your template produces sheets that read as your office's sheets. A team that works from a guess produces sheets your staff redraws. The difference is almost entirely set in the first days, by what your office sends and by how the team checks it before drawing.

Small practices tend to hold their standards in two places: the Revit template, and the head of the person who built it. The first can be sent. The second has to be written down, at least as a short list, before a team outside the office can follow it. This guide sets out both, then gives a checklist table your office can reuse.

The files that make up a Revit standard

Revit keeps an office standard in a few file types, each with a job:

• The project template (.rte). The starting point for a new project: view templates, object styles, line weights, fill and line patterns, text and dimension styles, schedules, sheets and the browser organization. A project started from the template inherits all of it.
• The project file (.rvt). The live model. For a set already under way, the model itself is the standard: whatever the template once said, the model shows how the office actually draws.
• Families (.rfa) and family templates (.rft). Title blocks, tags, view titles, annotation symbols, doors, windows, casework and detail components. A family is built from a family template and saved as a family file.
• The keynote file. A tab-delimited text file that holds the office's keynote numbers and text, which Revit reads to place keynotes and build keynote legends (Autodesk help).
• The shared parameters file. A text file that defines parameters shared between families and projects, such as the custom fields a title block or a door tag reads. Autodesk advises managing it from inside Revit, in the Edit Shared Parameters dialog, without editing it by hand (Autodesk help).

A team given the model but not the keynote file or the shared parameters file sees blank tags and empty title block fields. Send the files together, from the same location your office uses, and say which versions are current.

The Revit version and the upgrade that cannot be undone

Revit models are not backward compatible. A model opened and saved in a newer release is upgraded, and it cannot be opened, saved back or converted to the earlier release afterward; Autodesk's remedy for an accidental upgrade is a backup made before it (Autodesk support). A model saved in a newer release also cannot be opened in an older one (Autodesk help).

That makes the release year the first line of the handoff. The team works in the same release as your office, and nobody upgrades the model without your office's written decision. The same rule covers families: a family saved in a newer release cannot be loaded into an older model, so families built by the team are built in your release.

Worksharing and where the model lives

Your office's model should stay in your environment wherever possible, under your worksharing rules. Two setups are common.

• A central model on a file share. Each person works in a local copy and synchronizes with the central file. The team needs access to the share, usually through the office's VPN or a synced folder, and a worksets plan that says who owns which part of the building.
• Revit cloud worksharing on Autodesk Construction Cloud. The model lives in the cloud project, and each person who opens it needs a cloud worksharing subscription, which Autodesk sells as Forma Design Collaboration, formerly BIM Collaborate Pro (Autodesk support). Access is granted by your office as project members, and removed by your office at the end.

Either way, the handoff states the worksets, the synchronizing habits your office expects, and who may create or delete worksets. TECTO Studio puts the work in your environment where you provide one, with your access controls and your worksharing rules.

The standards that live outside the files

A template shows how a sheet looks. Several decisions it does not show have to be written down:

• Sheet numbering. The office's numbering convention for each series and how new sheets are inserted.
• View naming and browser organization. How views are named, which view template each view type uses, and how the project browser is sorted.
• Detail library. Where the office's standard details live, whether as drafting views in a library model or as families, and which are current.
• Dimension and annotation habits. Dimension strings to face of stud or to grid, where notes go, how much is keynoted and how much is typed.
• Consultant links. Which consultant models are linked, from which issue, and who reloads them.
• Issue procedure. How an issue is named, dated and transmitted, and who approves it; the title-block check lists the items every sheet passes before issue.
• A BIM execution plan, if the project has one. Owners and larger clients sometimes require one; it overrides office habit where the two differ.

One page is enough for most offices. A redlined sheet from a past project, marked with what the office likes and dislikes, often says more than the written page.

What a template review checks

Before any drawing, the studio reviews the template and the model. TECTO Studio's terms set that review at half a day at no charge, and quote any setup work the template needs as a fixed fee. The review looks at:

• Completeness. View templates, title blocks, tags and schedules exist for every sheet type on the package's sheet list.
• Consistency. Object styles and line weights produce the office's printed look, and the families in the model match the template's families.
• Data. The title block and tags read shared parameters and project information, with no typed text that will drift.
• Health. Warnings count, unused families and views, linked files that no longer resolve, and file size.
• Gaps. What the package needs that the template does not have, listed with a proposed fix for your office to approve.

The output is a short written list for your office: what is ready, what needs a decision, and what setup work the package needs before the first sheet.

The handoff checklist

When the template is thin

Many small practices do not have a complete template; they have the last project. That works. The team starts from the most recent model that matches the project type, the review lists what is missing, and your office decides which gaps to fill now and which to leave for later. A template built during one package is a lasting asset for the office, and it shortens every handoff after it.

The same work pays back with a hire. A new employee learns the template in weeks at a desk; the cost guide sets those weeks next to the wage. And a practice that hands over design development instead of CDs alone gets a model built on its template from the start.

Sources

• Autodesk, About Editing the Keynote File, Revit 2026 help.
• Autodesk, Create Shared Parameter Files, Groups, and Parameters, Revit 2019 help.
• Autodesk, Backward compatibility of Revit with earlier releases of the software, support article.
• Autodesk, Revit file cannot be opened because of version issues, Revit 2024 help.
• Autodesk, Cloud worksharing requires a subscription to Autodesk Forma Design Collaboration, support article.