Ten pillars of a well-built Revit Template

Too often we leap before we look - the value of a well-built template is often underestimated due to the non-billable hours required to be invested in its setup. In this article, we aim to cover the core pillars of what I think all Revit templates should be built to achieve.

It probably goes without saying, but every company using Revit should create (and continuously develop) their own Revit template. Autodesk did not design Revit to come out of the box with guns blazing; on the one hand this is unfortunate, on the other it forces companies to revisit and refine their own workflows.

I've built my fair share of Revit templates during my career, and have learnt each time that there are a core set of principles all of these ended up requiring and benefiting from. Some firms struggle to look past their line weights and patterns, but I'll take you beyond this to what really matters when developing a template.

BIM Guru's Template

For those keeping an eye on our website, you may have noticed we now have an online store! Currently there are 4 products, one of which is a Revit 2020 architectural template - we will be announcing some promotions for this shortly on our social channels.

Coming soon: The BIM Guru Revit template!

Pillar 1: Pro-active 'Buy-in' Strategies

Not seen here: The afor-mentioned

More often than not, this is actually the most critical yet time consuming aspect of developing a template. The moment everyone finds out what you're doing, every person in the company and their dog has an opinion about what the correct masonry hatch is and why 'their line weights' are better than the company standards.

I've always found that the best process for buy-in is as follows:

  1. Research industry standards that may benefit your template (e.g. ISO19650)

  2. Prepare an action plan (make it clear and concise)

  3. Get approval from the management level of your company

  4. Hold a single workshop where anyone may attend and propose ideas

  5. Blinkers on, roll out the changes

  6. Pilot the changes on a project that can afford some testing delays

It is crucial that during step 4 (a workshop) all attendees are encouraged to reach a consensus on their ideas - conflicting opinions should not be left unmediated, otherwise they will rear their heads again at a later date (restarting the process essentially). Have reasoning behind your choices ready so you can more easily dismiss ideas with less merit for collective needs.

Pillar 2: Order of Dependency

The actual updating of a template usually best follows a specific order. There are certain aspects that rely on previous ones being established, for example: wall types may require shared parameters to be set up prior. Your goal should be to avoid 'doubling back' in as many aspects as possible.

Aspects of a template: A lot to consider!

In my experience, this tends to be the order of creation that invokes the least backtracking due to dependency between elements:

1. Establish naming conventions

2. 2D Graphical standards

  • Line Weights

  • Line Patterns/Styles

  • Fill patterns, filled region types

  • Fixed/spot dimension types

  • Grid/Level/View reference types

3. Systems

  • Shared parameters

  • Keynotes

  • Assembly codes

  • Material library

4. System families

  • Basic wall types

  • Curtain panel/wall types

  • Floor/Ceiling/Roof types

  • Railing types

5. Loadable families

  • Essentials only, eg:

  • Door/Window families

  • Parking space families

  • Casework families

  • Will vary depending on your discipline

6. Views and Sheets

  • View types and templates

  • Titleblocks

  • Base views and sheets

Pillar 3: Well documented systems

A common trap to fall into when developing a template is to internalize your thought process - it is an intense process, and the blinkers always come on to some degree. Remember that others will need to use your template, and should be able to understand the logic applied to each system used.

If you use national/international standards to form aspects of your template, make sure these are clearly referenced and made available to the right people so they can audit and maintain their projects against these. Remember, not everyone is aware of these standards beyond the surface level!

System/rule views: We use many in our templates!

Good practice is often to include a set of legend or drafting views somewhere in your project browser where users can visit and view the systems/rules in place so they can better learn about the expected ways to use the template - over time these will become second nature to them.

Pillar 4: Adaptability

If your template is larger than 30MB, chances are you've put too much into it. A well known methodology applied to templates in larger companies is the 'Chassis/body/trim' approach. Essentially, the template should act as a framework which can receive changes to suit the needs of the project it will be used on.

Chassis/Body/Trim: Make your template adaptable!

Just as a concept designer has no need for LOD400 content, a technician has no need for a concept presentation view template. By storing various aspects of your template in separate models you can keep the template light, containing the essential bare bones only.

Revit provides us with two powerful template aids; 'transfer project standards' and Dynamo. The first allows us to migrate in additional template aspects, whilst the latter allows us to make blanket additions/changes/removal to the template itself.

Make sure that when you gauge what your user's need, you take into consideration all types of users and project stages - the lighter you can make the template, the more likely users will do things the intended way.

Pillar 5: Universal_Naming-Conventions [1]

Naming is an important principle in any template based exercise, however it's crucial that the number of conventions being used should be minimized as much as possible. A common mistake I've made in the past is inventing a convention for each system, for example: naming materials one way, but naming family content entirely differently.

My core goals when it comes to naming are:

  • Search-ability

  • Human readability

  • Process-ability

Pillar 3 is also crucial here, naming conventions should be documented extensively. If you can't summarize the convention in less than a few paragraphs, chances are it's too complex and people will get it wrong when they create new elements.

Pillar 6: Render-ready Materials

One of the best reactions I got from a user who was trying out a new template was when they came to the point of rendering a 3D view. They approached my desk, asked me how long it would take to prepare the model for rendering, and my reply was simply 'as long as it takes to hit the button'.

What the user did not realize is that whilst I built the template I had also prepared and applied render-ready materials to all the content we had available. Whilst this took time, the enjoyment users suddenly gained from their models was evident to everyone (including management).

Materials: Provide your template with the essentials

Avoid leaving 'Default' or '<By Category>' as the material for all the 3D elements in your model. Set up a shared material library as soon as you begin developing 3D objects for your template, and continuously update and apply them as you go. When you build loadable families, it is critical you manage their materials via a shared library as they will ultimately source their materials from the project's version of the material once loaded - this means a consistent naming convention between project and family is critical.

Consider setting up a low/hi-res image management system where you can quickly switch materials over to higher quality versions as well, so that you don't put as much pressure on model performance when not rendering.

Pillar 7: Structured Data

Whilst building a template, this is also the moment where you will establish the data structuring principles. Shared and project parameters you introduce at this point will likely persist for many years to come in projects, so it is critical that they are well named and structured.

Visual Ergonomics: Data should be easy on the eyes as well as the brain!

Try to avoid replicating parameters already present in the model such as Marks and Keynote codes unless there is a good reason to do so. The more redundancy a template contains, the more likely users will not understand how they are meant to use it.

A good practice when using Shared Parameters is to provide them with a company prefix - this way a user can always identify when a parameter is shared in nature (ours for example is 'BG_'). Try not to introduce parameter names like 'Width/Depth/Height' that are easily confused with parameters that come with Revit by default.

Pillar 8: Browser Organisation

I'm still surprised to this day by how many users are not aware of the ability to reorganize the project browser. Since my very first project this habit has remained with me, and I can't help but set it up in any project I come across without it established.

In my experience, the best method to organize your browser is:


  • Two sorting (shared) parameters; Set/Series

  • Optional third level; View type

  • View templates apply the sorting fields

  • View types apply view templates on creation


  • Two sorting (shared) parameters; Set/Series

Locking down views: The process by which we keep our views organised.

If you can set up your view types with pre-applied view templates, your project will essentially be able to keep itself organised with minimal effort required by the user - this is a big time saver on large scale projects.

Pillar 9: Classification Frameworks

Try not to reinvent too many wheels when you set up or adjust a template - there are a lot of well-worn wheels out there already in motion! Such systems as keynoting, assembly coding and shared parameter conventions have precedent out there which may be worth reviewing prior to inventing a company specific system.

Such resources to consider are;


Assembly Codes

Shared Parameters

Don't be afraid to ask other professionals what they use as well, most companies wont have an issue with letting you know any third party systems they follow as it doesn't really affect their competitiveness in the market compared to how they implement and work with the systems specifically.

Pillar 10: Starter Views and Sheets

The worst template I ever had to use provided the user with 300MB worth of pre-loaded families, and not a single view or sheet to place them on. A friendly template should provide the user with enough to orient them in the Revit model environment at the very least.

As a rule of thumb, I try to provide the following:

  • Some levels for the user to take advantage of

  • A set of grids spaced at 8m x 8m to cover an A1 page

  • An A1 suitable scope box at 1:100 scale

  • 1:100 GA plans for each level

  • 1:100 cross/long section through all levels

  • 1:100 exterior elevations on all sides of the scope box

  • View templates applied to all views and view types in use

  • Base sheets to support the above views, pre-placed

Getting started: A good example of a starter sheet/view

Whilst the user will likely need to adjust all of the above to suit their project, more often than not they will be far more comfortable beginning with something as opposed to nothing. Pre-applied view templates will also quickly introduce the user to the way in which the project browser is organised by the view templates.

Some much needed love

Chances are, at least one of the above pillars might be missing from the way you already set up your project template. Given many of us are in a state of 'downtime', now might be the perfect time to revisit your company template and apply some of these best practices.

We hope this article helps guide you in future, and leads to further discussion with other professionals who no doubt have their own opinions on what makes a Revit template successful.

- Gavin Crump @BIM Guru

1,481 views0 comments

Recent Posts

See All