Detailing in Revit: From the Coordinated Model to the Detail Sheet

Where the model stops being useful

A coordinated model wins the clash review, passes the QA rules, exports a clean IFC, and then hits the wall table. Somebody has to draw the parapet.

At that point the promise that made BIM attractive, model it once and every drawing updates, quietly stops applying. Nobody models a sealant bead. Nobody models a drip groove, a compressible filler strip, or the fold in a flashing. Those things live at a scale the model was never built to hold, and yet they are what the contractor actually builds from. So detailing becomes the part of the job where a BIM team either keeps its standards or loses them.

Most offices lose them. The model is governed, the sheets are governed, and then the detail set is whatever eleven people drew over four years at four different line weights, half of it exploded from a 2004 DWG library. This guide is about closing that gap: deciding where each detail should live, drawing it once, and keeping it honest against the model it claims to describe.

It is written for the BIM coordinator, documentation lead, or architect who owns the detail set on a live project.

The three places a detail can live

Every detail you draw in Revit sits in one of three places. Choosing correctly is 80 percent of the job, and it is a decision most teams make by accident.

1. Model geometry. Real 3D elements: wall layers, floor build-ups, roof assemblies, sweeps, host-based components. Cut them and the detail draws itself.
2. View-specific 2D on top of a model view. A callout of the real model, embellished with detail components, filled regions, and detail lines that exist only in that view.
3. A drafting view. A pure 2D drawing with no model behind it at all. Nothing in it knows the building exists.

Here is how they compare on the things that actually matter six months into a job.

	Model geometry	View-specific 2D over model	Drafting view
Updates when the model changes	Yes, automatically	Partly, the model half only	No, never
Reusable on the next project	No, project-specific	No, tied to that view	Yes, portable
Schedules and quantities	Yes	No	No
Effort to produce	High	Medium	Low
Risk of describing a building you are not building	Low	Medium	High
Model performance cost	Medium	Low	Almost none
Right for	Assemblies, junctions that repeat in 3D	Project-specific conditions at a real location	Generic and typical details, manufacturer standards

The practical rule: model what the building is made of, draw what the building is trimmed with. A wall assembly with its insulation, cavity, and cladding zone should be modelled, because the model has to cut it correctly in twelve other places and schedule its materials. A membrane return, a bead of sealant, and a proprietary starter track should be 2D, because modelling them buys you nothing and costs you file size, regeneration time, and a lifetime of maintenance.

The failure mode at both extremes is easy to spot. Teams that model too much end up with a 900 MB file, a wall type list with 60 near-identical entries, and a modeller who now owns the sealant schedule. Teams that model too little end up with a beautiful set of drafting views that no longer match the building, and a site query every Tuesday.

Detail level and view range: what you are actually seeing

Before you draw a single line, understand what Revit is already showing you. A surprising number of “the detail is wrong” complaints are actually view settings.

Detail Level (Coarse, Medium, Fine) is a per-view property, and it does two things. It controls whether compound structure layers in walls, floors, and roofs display as separate layers, and it controls the visibility of geometry inside families that has been assigned to a detail level. A door family often carries a simplified swing at Coarse and full frame geometry at Fine. If your detail looks empty, check that first.

View Scale matters more than people expect, because it drives annotation size and it interacts with Coarse Scale Fill Pattern settings. A detail set at 1:5 and a detail set at 1:20 can show identical geometry with wildly different apparent line weights.

View Range and the cut plane decide what is cut versus what is seen in projection. Elements that are cut take the Cut line weight from Object Styles. Elements in projection take the Projection line weight. This is why one detail reads crisply and the next looks flat: half the elements are not actually being cut.

Far Clip Offset on a section or callout controls how much background you drag into the view. Leave it unlimited and you get every wall, tree, and light fitting behind the detail, which you then hide element by element rather than fixing the setting.

Do not fix these per view. Fix them in the view template that governs the detail views, so the whole detail set behaves the same. This is exactly what view templates and graphic standards exist to control, and detail views deserve their own template, separate from plans and sections.

Callouts versus drafting views

The single most common detailing question on a live job is: do I cut this out of the model, or do I draw it from scratch?

Use a callout of the model when:

• The condition is specific to a real location in this building.
• The geometry behind it is already modelled correctly and you want it to stay true.
• The detail is likely to change because the design is still moving.
• You need it to be discoverable from the plan or section it belongs to.

Use a drafting view when:

• The detail is typical, generic, or the same on every project you do.
• The condition happens at a scale or with components you never intend to model.
• The detail comes from a manufacturer or a standard you are adopting wholesale.
• The model cannot produce a readable version of it without heavy overrides.

There is a third option most teams forget. Draw the detail once as a drafting view, then use a Reference Callout: place a callout on the plan or section at the real location, and point it at the existing drafting view instead of creating a new one. You get the callout bubble and sheet reference on the host view, with a single portable drawing behind it. Reference the same drafting view from fifteen locations and you maintain one drawing.

The same trick works with reference sections. If a typical wall section applies to six grid lines, mark all six and reference them to one view. What you must not do is copy a drafting view five times and edit each copy, which is how a set ends up with five slightly different versions of the same parapet.

Detail components do the real work

Detail components are 2D families in the Detail Item category. They are the workhorses of a good detail set, and the difference between an office that details fast and one that does not usually comes down to whether the library exists.

The types worth building or curating:

• Detail component families for profiles you draw constantly: angles, channels, studs, battens, cavity trays, DPCs, flashings, brick and block sections, timber sections. Build them with parametric sizes and a proper type catalogue rather than making a new family for every dimension.
• Repeating Detail Component, which arrays a single detail component along a path at a set spacing. This is what you use for brick courses, tile, cladding rails, decking, and standing seams. Draw it as a repeating detail, not as fifty copied components, and adjusting the run to a new length is one drag.
• Break Line, the masked component that lets a detail stop honestly instead of trailing off. It should be in every template.
• Insulation, a native Revit tool with a settable width. Use it rather than drawing squiggles.
• Detail Groups for clusters of components that always appear together, such as a full window head assembly. Edit the group once and every instance follows.

Two rules that keep the library sane. First, name components after what they are, not what they were for: DC_Flashing_Cavity Tray beats Detail 3 Bit. Second, load families through the office library, never by copy-pasting between live projects, or you will accumulate five variants of the same family with divergent parameters. This is a content governance question, and it belongs to the same owner who runs the office Revit project template.

Regions, lines, and why two details never match

Ask why the detail set looks inconsistent and you will hear “different people drew it”. The real answer is usually that the office never defined the graphic vocabulary, so each person invented one.

Filled regions are bounded 2D areas with a fill pattern and a boundary line style. They are how you show materials the model does not cut: mortar beds, screeds, sealants, generic fills. The trap is that everybody creates ad hoc filled region types, so you end up with Diagonal Crosshatch, Diagonal crosshatch 2, and Crosshatch-new. Define a fixed set of filled region types in the template, matched to the material fill patterns the model already uses, and lock the list.

Masking regions hide model geometry behind a detail without deleting it. They are legitimate and useful. They are also the number one way details start lying, because a masking region can hide a genuine conflict and nobody sees it again. Keep them deliberate and few.

Detail lines are view-specific and take a Line Style. If your office has not defined line styles with meaningful names and weights, people will use Thin Lines for everything and the whole set will read flat. Define a small palette (heavy cut, medium, light, hidden, centre) and train on it.

Line weights and Object Styles are the underlying control. Object Styles assigns each category its cut and projection line weight number; the Line Weights table maps those numbers to actual millimetres per view scale. Change the table and the entire set re-weights. This is a template-level setting that one person should own, because editing it mid-project changes every drawing at once.

A working hierarchy that reads well when printed:

1. Cut structural and primary elements: heaviest.
2. Cut secondary elements and finishes: medium heavy.
3. Elements in projection beyond the cut: medium.
4. Detail components and 2D annotation geometry: light.
5. Hatching, fills, and background: lightest, often halftone.

Building a detail library the office actually reuses

A detail library is not a folder of DWGs. It is a maintained Revit project containing drafting views, the components they use, and a numbering system, and it works only if it has an owner.

The setup that holds up:

1. Create a standard details project (a normal .rvt, not a template) containing only drafting views. Group them by element system: external walls, roofs, windows and doors, internal partitions, floors, thresholds, balustrades.
2. Name views systematically. Something like EW-101 Cavity Wall - Parapet sorts, searches, and reads on a sheet without further work. Number blocks by system so there is room to grow.
3. Pull details into a live project with Insert, Insert Views from File. Point at the standard details project, select the views you want, and Revit brings the drafting view plus every detail component family it uses. This is far safer than copy-paste between open sessions, and it is the single feature most teams do not know exists.
4. Never edit a library detail inside a live project and expect the library to update. It is a one-way copy. If a detail is wrong, fix it in the library and re-insert, and log the change.
5. Review the library on a cycle, not on inspiration. Once or twice a year, walk it against current regulations, current manufacturer systems, and the last two projects’ site queries. Details that generated a query are the ones to fix.
6. Version and date the library. When a project team asks “is this current”, there has to be an answer.

Ownership matters more than the structure. A library with a named owner and a change log stays useful for a decade. A library that everybody can edit and nobody maintains is untrustworthy within about eighteen months, and once a team stops trusting it they go back to copying details out of the last job, which is where inconsistency comes from in the first place.

The exploded CAD detail trap

Almost every office carries a legacy DWG detail library, and the tempting move is to import those DWGs into drafting views and be done in an afternoon.

Linking a DWG into a drafting view and leaving it linked is defensible as a stopgap. Exploding it is not. A full explode of a CAD detail does the following to your project:

• Creates a new line style for every AutoCAD layer in the file, permanently, in the project. Import ten details and your Line Styles list has 200 entries with names like A-DETL-THIN.
• Brings in every text style and dimension style as new types.
• Converts hatching into large numbers of individual line elements, which is slow to regenerate and worse to edit.
• Loses the layer structure that made the CAD file manageable in the first place.
• Cannot be undone cleanly. Purging line styles that are now in use across the model is painful work.

The line style pollution is the part that bites hardest, because it spreads. Copy one exploded detail into another project and the styles travel with it. Within a year the office standard list is unusable and nobody can find the five styles they are supposed to use.

The honest options, in order of preference:

1. Redraw the detail natively using detail components and the office line styles. Slower per detail, correct forever, and it forces a review of content that is often out of date anyway.
2. Link the DWG into a drafting view, keep it linked, and treat it as a temporary placeholder with a visible task to redraw it.
3. Import without exploding, if you must, and accept it as legacy.

Do not attempt to convert 400 details in one push. Convert on demand: when a project needs a detail, redraw it properly and put the native version in the library. Three projects in, most of the details you actually use are native, and the ones you never converted were the ones you never needed.

Keynotes, annotation, and the link to the specification

A detail with no text is a drawing. A detail with the right text is a specification instruction.

Keynotes connect a detail annotation to an external keynote text file, so the wording of A-10 Cavity tray, stainless steel is defined once for the office and used everywhere. Element keynotes read from the material or type; user keynotes are placed freely, which is what most detailing uses. The benefit is not typing speed, it is that when the wording changes, it changes across every sheet at once, and the keynote legend on the sheet stays synchronised.

The discipline that makes keynotes work: the keynote file lives with the office standards, has an owner, and is not edited per project without a decision. A project-specific keynote file forked from the office one on day two, then edited freely, is functionally the same as free text.

Text notes should be limited to the small number of things that are genuinely project-specific. If a note appears on more than three details, it is a keynote.

Dimensions on details need their own type with a smaller text size, appropriate witness line gaps, and a consistent unit format. Detail dimensions at plan-dimension settings look wrong at 1:5 and crowd the drawing.

Tags versus text. Where the detail cuts real model geometry, tag it rather than describing it, so a change in the model shows up in the annotation. This is one of the few places detailing gets to keep the BIM promise, and it is worth the setup.

Keeping details honest against the model

The danger with drafting views is not that they are 2D. It is that they are disconnected, and disconnection is invisible. A drafting view showing a 100 mm cavity will keep showing 100 mm forever, including three months after the facade consultant moved it to 150 mm and the model was updated correctly.

Four practices that catch this:

1. Cut a real section next to the typical detail during design reviews. Put the model section and the drafting view side by side and compare. Differences show up in seconds. Do this at each design stage gate, not at issue.
2. Keep a register of which drafting views describe which model assemblies. A simple spreadsheet or a shared parameter on the view is enough. When a wall type changes, you can find every detail claiming to describe it.
3. Treat a changed wall type as a detail review trigger. Any change to a compound structure that appears in the LOD expectations for the current stage should generate a check of the associated details.
4. Prefer callouts over drafting views for anything still moving. Switch to a portable drafting view only when the condition is settled and repeating. Early-stage drafting views are how a set goes stale.

There is also a governance answer. Whoever owns the model owns the detail set. Splitting them, with one person modelling and another detailing in isolation, guarantees drift because there is no one whose job is to notice the mismatch.

What detailing costs the model

Detailing looks free because 2D elements are small. In volume, they are not.

The measurable costs:

• Detail lines and filled regions are view-specific, so they do not slow the model globally, but a single view holding thousands of exploded CAD lines can take many seconds to open and pan, and it regenerates on every graphic change.
• Detail groups behave well; copied component clusters do not. A hundred instances of a group is much lighter than a hundred copied sets.
• Every imported CAD file stays in the project until purged, including ones you deleted the instance of. Manage Links and Purge Unused are the cleanup tools.
• Line style and text style bloat slows every dialogue in the project and pushes people into wrong selections.
• Over-modelled detail geometry is the expensive one. Modelled sealant, modelled fixings, and modelled trim multiply element counts across the whole building, not just one view. This is a common contributor to the symptoms in slow Revit models.

If a detail view takes more than a few seconds to open, look for exploded CAD before you blame hardware.

A pre-issue detail QA checklist

Run this on the detail set before every issue, not just the big ones.

• Every detail on a sheet is referenced from at least one plan, section, or elevation, and the reference bubble shows the correct sheet and detail number.
• No detail views sit unplaced on a sheet unless deliberately held back.
• View titles match the office naming convention and read correctly at print size.
• Scales are stated correctly and are consistent for equivalent detail types.
• Line weights print correctly on a real paper check, not just on screen.
• Filled region types come from the approved list; no ad hoc types created this week.
• Masking regions are deliberate and are not hiding a real conflict.
• Keynotes resolve to current text and the keynote legend on each sheet matches the details shown.
• Typical details still match the current model assemblies they describe.
• No exploded CAD introduced since the last issue. Check the Line Styles list for new arrivals.
• Break lines used where details terminate, so nothing trails off ambiguously.
• Dimensions use the detail dimension type and read cleanly at scale.

Two of these, the line styles check and the typical detail comparison, catch the majority of quality problems and take about ten minutes between them.

Common mistakes

Detailing in the model view instead of a callout. Add detail components to a working plan and they appear in every view at that scale, or nowhere useful. Detail in a dedicated callout or drafting view.

Copying a drafting view instead of referencing it. Five copies means five things to update and four chances to miss one.

Explode-importing the legacy DWG library. Fast today, unusable line style list forever. Covered above, and it is the mistake with the longest tail.

Modelling what should be drawn. Modelled sealant and fixings inflate the model, slow every view, and rarely improve a drawing.

Drawing what should be modelled. The mirror error. If a junction appears in eight places and needs to schedule, model the assembly properly and cut it.

No owner for the detail library. Without one, the library is stale in eighteen months and the office quietly reverts to copying from the last job.

Ad hoc filled region and line style types. Each one is small. Two hundred of them make the standard unenforceable.

Details never re-checked against the model. The most expensive mistake, because it surfaces on site as a query, a variation, or rework, long after it was cheap to fix.

Detail numbering invented per project. A consistent system means the same detail carries a recognisable reference across jobs, which helps everyone from the technician to the contractor. Sheet organisation belongs with sheet and view management.

How to start

You do not need a library project and a governance policy before you can improve this. Do the following in order.

1. Audit one recent project’s detail set this week. Count the drafting views, count the line styles, and note how many details came from exploded CAD. The number will make the case for you.
2. Fix the detail view template. Detail level, scale defaults, far clip, and visibility settings, applied to every detail view. One hour, immediate consistency.
3. Define the graphic vocabulary. Five or six line styles, a fixed list of filled region types, one detail dimension type, one detail text type. Put them in the office template.
4. Build the first twenty detail components. Start with the profiles you draw every week, not the exotic ones. Parametric, type catalogue, sensibly named.
5. Create the standard details project and put ten details in it, redrawn natively, numbered by system. Ten good details used on the next job proves the idea faster than a hundred unconverted ones.
6. Use Insert Views from File on the next live project and note how long it takes. That number is your business case for continuing.
7. Name an owner and a review date. Without this, steps 1 to 6 decay.

Detailing is where a BIM process meets the part of the building that BIM does not describe well, and pretending otherwise is why so many good models produce mediocre drawing sets. Decide deliberately what belongs in the model, draw the rest once, keep the two checked against each other, and the detail set stops being the weak end of the deliverable.

If you want to build these habits alongside the modelling and coordination workflows that feed them, the Revit and BIM coordination courses on Archgyan are taught from live project practice rather than feature tours.