Revit View Templates and Graphic Standards: A Practical Guide for BIM Teams

Open any set of drawings produced by five different people on the same Revit project, and you can usually tell who drew what. One plan has hairline walls, another has heavy ones. Section cuts jump from black poché to grey. A door tag on sheet A-101 looks nothing like the same tag on A-201. None of this changes the geometry, but all of it makes the set look amateur and slows down every check.

Graphic consistency is not a cosmetic nicety. It is one of the clearest signals of a mature BIM team, and it is almost entirely controlled by a small set of tools that most Revit users touch only when something looks wrong. This guide walks through those tools in the order they actually matter, then gives you a rollout plan for making the standards stick across a team.

What Graphic Standards Actually Mean in Revit

A graphic standard is the set of rules that decide how every line, fill, tag, and annotation looks on a printed sheet. In a traditional CAD office this lived in a pen table and a layer standard. In Revit the same job is split across four layers of control: object styles, view templates, filters, and view-specific or element overrides.

The trap is that any of those four can override the others, so two people can produce different-looking drawings from the same model without either of them being wrong. The fix is not more overrides. It is understanding which layer should own each decision, then pushing every setting up to the highest layer that can hold it. Standards live at the top of the hierarchy. Exceptions live at the bottom, and there should be very few of them.

The Graphic Control Hierarchy: Who Wins When Settings Collide

Before you touch a single line weight, you need to know the order of precedence. When two settings disagree about how an element should look, Revit resolves the conflict from the most specific control to the most general. The more specific setting wins.

Control level	Scope	Wins against
Element override (per-element in a view)	One element, one view	Everything below
Filter override	Elements matching a rule, in views using the filter	View template, categories, object styles
Category override in the view (Visibility/Graphics)	A whole category in one view	View template default, object styles
View template	Every view assigned to it	Object styles
Object styles	The whole project	Nothing, it is the base

Read that table from the bottom up and a strategy falls out. Set your defaults once in object styles so the entire project starts from a sane baseline. Use view templates to standardise the look of each type of view. Use filters for conditional graphics that follow data. Reserve manual element overrides for genuine one-offs. Every time someone right-clicks an element and picks Override Graphics in View, they are working at the top of that table, and they are quietly breaking your standard for everyone who reuses that view later.

Object Styles: The Foundation of Line Weights and Colours

Object styles (Manage tab, Object Styles) set the default line weight, line colour, line pattern, and material for every category and subcategory in the project. This is the layer people forget, because view templates usually mask it. But it is the baseline that everything else inherits from, and getting it right removes a huge amount of downstream fiddling.

A few principles that hold up on real projects:

• Set projection and cut line weights separately. A wall in projection (seen in elevation) should read lighter than the same wall cut in plan. Object styles let you set both, and this single distinction does most of the work of making a plan look like a plan.
• Work with subcategories, not just categories. A door has a panel, a frame, an elevation swing, and a plan swing, each on its own subcategory. Standardising these is what makes families from different sources sit together on a sheet without looking mismatched.
• Keep colour out of object styles unless you print in colour. For black and white document sets, leave line colours black and let line weight carry the hierarchy. Colour belongs in filters and working views, not in the printed standard.

Because object styles are project-wide, the smart move is to define them once in a company template and never rebuild them per project. More on that below.

View Templates: Your Enforcement Layer

A view template is a saved bundle of graphic settings you apply to a view. When a view is assigned a template, the controlled settings are locked and greyed out in that view, which is exactly what you want: the drawing cannot drift because nobody can nudge it by accident.

A view template can control the following, and you decide which of these it owns by ticking the Include column in the template editor:

• View scale and detail level
• Visibility and graphics overrides for model categories, annotation categories, and imports
• Filters applied to the view
• Detail level and parts visibility
• Graphic display options (shadows, sketchy lines, depth cueing)
• View range, phase filter, and discipline (for plans)

The include list matters as much as the settings. If you leave View Range unticked, each plan keeps its own cut plane while still inheriting your line and visibility rules. That is usually what you want, because a ceiling plan and a floor plan share graphics but need different cut planes. Deciding what a template controls is a design decision, not a default.

Building a View Template Library That Scales

One view template is not a standard. A usable library covers every combination of view type, discipline, and drawing purpose your team produces. A mid-size architecture team typically ends up with something like this:

• AR Floor Plan, AR Reflected Ceiling Plan, AR Site Plan
• AR Building Section, AR Wall Section, AR Detail
• AR Elevation (exterior), AR Interior Elevation
• Working views: Coordination Plan (colour, all disciplines visible), Design Review 3D

Name templates so they sort logically in the dialog and tell you their scope at a glance. A prefix for discipline (AR, ST, ME) followed by view type reads well and groups cleanly. Avoid names like “Plan 2” or “Manish working” that mean nothing to the next person. The library is a shared asset, so it should read like one.

Two rules keep the library healthy. First, every sheet-bound view gets a template, no exceptions. A view with no template is a view that will drift. Second, working views (the messy, colourful views you model in) can use looser templates or none at all, but they never go on a sheet. Keeping working graphics off the document set is half the battle.

Filters: Conditional Graphics That Do Real Work

Filters override the look of elements that match a rule, and they are the most underused tool in this whole stack. Instead of manually colouring elements, you write a condition once and Revit applies the graphics automatically as the model changes.

The high-value uses on a BIM project:

• Colour by workset or by linked model on a coordination view so you can see at a glance whose element is whose.
• Fire rating filters that flood-colour rated walls, turning a compliance check into a visual one.
• Phase or new/existing/demo filters that override demolished elements to a dashed light pattern without touching phasing graphics.
• Filters that flag missing data, for example any element with an empty Type Mark or Fire Rating, so QA problems show up as loud colours in a review view.

Because filters live inside view templates, a coordination filter set travels with the template. Build the filter once, add it to the Coordination Plan template, and every coordination view in the project inherits it. That is standardisation and automation in the same move.

Line Weights, Line Patterns, and the Pen Table Mindset

Revit maps line weights to actual printed thicknesses in Manage, Additional Settings, Line Weights. There are 16 numbered pens, and each one has a printed thickness that can change per view scale. This is the direct descendant of the CAD pen table, and it is where the physical weight of your drawings is decided.

Two things trip people up. First, line weight number is not thickness. Pen 5 might print at 0.35 mm at 1:100 and 0.50 mm at 1:20, because thick lines need to grow as you zoom in. Set the scale-dependent table once and every view respects it. Second, object styles and overrides refer to these pen numbers, not to millimetres. So the workflow is: define the millimetre values in the line weight table, then assign pen numbers in object styles. Get the table right and your whole set gets consistent weight for free.

Custom line patterns (dashed, dash-dot, hidden) belong in the company template too. Rebuilding a “property line” or “centreline” pattern on every project is wasted time and a source of drift.

Locking It Down: Making Standards Stick Across a Team

Setting all of this up once is easy. Keeping it consistent across projects and people is the real work. The mechanism Revit gives you is the company template project (an .rte file) plus Transfer Project Standards.

Put your object styles, view templates, filters, line weights, line patterns, and fill patterns into a single office template. Every new project starts from it, so the standard is present on day one instead of being reconstructed under deadline pressure. For projects already underway, or when you update the office standard, use Transfer Project Standards (Manage tab, Insert from File area) to push updated view templates, object styles, and filters from the template file into the live project. Open both files, run the transfer, and choose which categories to bring over.

A few habits that hold the line:

1. One person owns the template. Standards fragment the moment everyone can edit them. Nominate a BIM lead who reviews and publishes changes, and treat the .rte like source code.
2. Version the template. Keep dated copies so you can see what changed and roll back a bad update.
3. Assign templates through the Project Browser, not per view. Right-click a browser group and apply a template to many views at once, so a new plan cannot slip onto a sheet unstyled.
4. Purge before you ship. Unused view templates and filters accumulate and confuse the next user. Purge Unused (Manage tab) keeps the list honest.

Common Mistakes That Break Graphic Consistency

Even with a good setup, a few recurring habits quietly undo it:

• Manual overrides instead of filters. Someone selects a wall, overrides it to red, and moves on. The next person duplicates that view, the override rides along, and now the standard is broken in two places. If a graphic depends on a rule, it belongs in a filter, not an override.
• Views on sheets without a template. The single biggest cause of inconsistent sets. If a view is on a sheet and has no template, it is an accident waiting to print.
• Detail level set per view. Coarse, Medium, and Fine change how families draw. Let the view template own detail level so a plan and its enlarged plan match.
• Colour bleeding into the document set. Coordination colours from a working view get copied onto a sheet. Keep colour views and document views cleanly separated by template.
• Rebuilding standards per project. If your object styles and view templates are not in an office template, every project is a fresh chance to be inconsistent. Centralise once.

A Practical Rollout Plan for a Team

If your standards are currently living in someone’s head, here is a sequence that gets them into the tools without stopping production:

1. Audit one finished project. Pull the printed set and list every view type you produce and how each should look. This becomes your target.
2. Fix object styles first. Set projection and cut line weights and subcategory graphics on a clean project. This is the baseline everything inherits.
3. Build the view template library for each view type you found in the audit. Test each one on a real view and print to check the weights.
4. Add filters for coordination, phasing, and QA, and bundle them into the relevant templates.
5. Save it all into an office .rte template. This is the deliverable. Everything above is worthless if it does not end up here.
6. Roll out with Transfer Project Standards on live projects and make the .rte the default for new ones.
7. Assign an owner and a review cadence. Standards are maintained, not finished. A monthly review of new filters and templates keeps drift out.

Done in this order, a small team can go from inconsistent to standardised in a week of focused work, and the payoff compounds on every project after.

Where This Fits in a BIM Workflow

View templates and graphic standards sit at the boundary between modelling and documentation, which is exactly where a lot of BIM value is won or lost. A firm that has this dialled in spends its review time on the design, not on why one section looks heavier than another. It onboards new people faster, because the standard is in the tools instead of in tribal knowledge. And it produces sets that look like they came from one hand, which is what clients and reviewers quietly reward.

If you want to build these skills properly, from object styles through coordination-ready view setups, our practitioner-led Revit and BIM courses walk through the exact workflows real firms run. You can explore them at Archgyan Academy and start standardising the way your team documents.