How to Build a Parametric Sprinkler Family in Revit

Most architectural teams never author an MEP family, and then one day a fire protection consultant sends over a sprinkler that is a solid grey lump with no plan symbol, no coverage indicator and no connector. It places on a face, it looks vaguely correct in a section, and it is useless for everything you actually need it for: reading a reflected ceiling plan at 1:100, checking that the sprinkler grid clears the light fittings, and letting the model carry a real piping system.

That is the gap this build closes. A sprinkler is a small piece of geometry wrapped in a lot of behaviour, which makes it one of the best families to author if you want to understand how Revit families really work. In one object you meet face based hosting, a revolve, a nested annotation family, detail level visibility control, a Yes/No parameter driving IF formulas, a pipe connector, and the category specific parameters that only appear once the family is in the right category. If you can build this, you can build most of what your discipline needs.

The walkthrough below follows a real recorded build from the Archgyan Revit channel, with links to the exact moment each step happens. If you have never authored a family before, start with the Revit family creation fundamentals guide and the parametric door family walkthrough, then come back. For where this object sits in a wider model, the Revit MEP modeling fundamentals guide covers systems and connectors more broadly.

Start face based, then change the category before anything else

The build opens at File, New, Family with the Metric Generic Model face based template, and the very next action is switching the family category to Sprinklers under Family Category and Parameters. If Sprinklers does not appear in the list, turn on the filter that shows categories from all disciplines first, then select it.

Those two decisions are the foundation and neither is easy to undo well. Face based hosting is what lets the sprinkler sit on a ceiling, a soffit or the underside of a slab and stay attached when that host moves. The alternative, a ceiling hosted template, ties the family to one host type and breaks the moment the design swaps a suspended ceiling for exposed services.

The category matters more. Sprinklers is not a label. It controls which schedule the object lands in, which tag reads it, whether it can carry a pipe connector, and, critically, which built in parameters exist at all. Orifice Size, Temperature Rating, K-Factor, Pressure Class, Coverage and Response only exist because the family is in the Sprinklers category. Author this in Generic Models and no later setting brings them back.

Colour your new reference planes so you can see what you added

Before drawing a single plane, the build creates a new subcategory in Object Styles. Under Manage, Object Styles, Annotation Objects there is a single Reference Plane category, so a new subcategory named something like “Reference Plane New” gets a red colour and a different line pattern. Every plane drawn from then on is assigned to that subcategory before it is drawn.

This looks cosmetic and it is not. The face based template already ships with its own planes, and by the time you have added the ones for the head, the drop, the offset and the recess, a front view of the family is a thicket of identical lines. When you later go hunting for the constraint that is pinning your extrusion in the wrong place, telling your planes from the template’s planes at a glance is the difference between a two minute fix and twenty minutes of clicking.

Reference planes go in first, dimensions second, geometry last. That ordering is the most reliable habit in family authoring: geometry locked to dimensioned planes flexes, geometry drawn free floating and dimensioned afterwards fights you.

Dimension first, then decide instance or type on every parameter

With the planes in, the aligned dimension tool measures between them, always dimensioning from the stronger reference plane to the weaker one, and each dimension becomes a parameter through Create Parameter on the options bar.

The set that comes out of this stage is Offset, Orifice Radius, Nominal Radius, Height and Head Height. What matters is not the names, it is the instance versus type decision made on each one:

Parameter	Scope in the build	Why
Offset	Instance	Every sprinkler sits at a different distance below its ceiling depending on the room
Height	Instance	Adjusted per placement alongside offset
Orifice Radius	Type	Fixed by the product, so it defines the type
Nominal Radius	Type	Derived from orifice size, so it belongs to the type
Head Height	Type	Part of the product geometry

Get this wrong and you feel it on site drawings, not in the family editor. A type parameter that should have been instance forces a new family type every time one sprinkler needs to drop 20 mm for a bulkhead, and you end up with thirty near identical types in the browser. The reverse is worse: an instance parameter that should be a type lets two sprinklers of the same nominal type carry different orifice sizes, and quietly breaks the schedule.

If you pick wrong, you are not stuck. The dialog has a checkbox that converts a type parameter to an instance parameter after the fact, which is used in the build to flip Height.

Sanity check the dimensions before you model any geometry

The template’s default spacing produces a sprinkler roughly a metre across, which is where the build stops and opens Family Types to put real numbers in: head height around 35 mm, total height around 60 mm, nominal radius around 5 mm, orifice radius around 15 mm, offset around 35 mm. Head height is then trimmed to 10 mm because 35 looked wrong once the geometry was there.

Flexing the skeleton before you draw is a rule worth internalising. Sketch a revolve at a metre wide, then rescale, and you will find lines that refuse to follow, constraints that pop, and a family that throws geometry errors for reasons that have nothing to do with the change you just made. Two small planes are also copied 1 mm apart and locked with their own dimension so those offsets hold whatever else moves.

Revolve the head, extrude the drop

The head is a revolve, which is the right choice for anything rotationally symmetrical: sketch the profile once, pick the axis, and Revit does the rest. In the revolve sketch the boundary lines are drawn to the reference planes, the SI shortcut snaps to intersections, the pick lines option locks the profile edge to the plane it should follow, and the axis line is locked as well before finishing.

Locking is the part people skip. An unlocked sketch line sitting exactly on a reference plane looks identical to a locked one and behaves completely differently: change the parameter and the plane moves while the geometry stays. Every line that should follow a dimension gets a padlock.

The drop is a separate extrusion, drawn as a circle on the floor plan reference level with Center Mark Visible switched on so it can be aligned to the planes, then a temporary dimension is made permanent and assigned to Nominal Radius. In the front view both ends are locked, one to the top reference plane and one to the offset plane. That is the whole shape: a revolved head and an extruded drop, both parametric.

At this point the build creates a second family type with different values and applies it. Always test with two types. A family with one type is a family whose parameters have never actually been exercised.

The recessed switch: one Yes/No parameter, two IF formulas

This is where the family stops being a shape and starts being a component. A real sprinkler is either pendent, hanging below the ceiling, or recessed, sitting flush in it, and nobody wants two separate families for that.

A new Yes/No instance parameter called Recessed is created and grouped under Constraints so it sits at the top of the properties list rather than being buried. Then the two dimensional parameters get formulas instead of fixed values:

Offset becomes if(Recessed, 0, Offset Actual)
Height becomes if(Recessed, 0, Height Actual) + Head Height

Note the shape of that. A separate driver parameter, Offset Actual, is introduced specifically so the formula has something to read. A parameter driven by a formula is read only in the project, so if you write the offset value directly into the formula, nobody can ever adjust it. The pattern is: one visible parameter the user edits, one formula driven parameter the geometry follows.

The head height added on the end is a correction made live in the video. With a plain conditional the recessed type sat entirely inside the ceiling, which the video calls out as wrong because the head has to sit slightly outside, so head height is added back into the formula and the head then stands a fixed amount clear of the ceiling, 15 mm in the demonstration. That is the sort of detail that only shows up when you flex the family in section, which is exactly why you build two types early.

A Depth instance parameter and an extra reference plane at the bottom arrive at the same time, so the recessed condition has somewhere to go rather than just collapsing to zero.

Load it into the project and find out what is missing

The family is saved and loaded into a project, then placed on a ceiling with Place on Face. It works in section. In the ceiling plan it is close to invisible, because a 30 mm object viewed at 1:100 is a dot.

That is where a lot of in house families stop, and it is the reason so many of them are unusable. A sprinkler in a reflected ceiling plan is not represented by its geometry. It is represented by a symbol.

Build the plan symbol as its own annotation family

You can draw a filled region directly inside the sprinkler family, and the video mentions that option, but the recommendation is to author the symbol as a separate Metric Generic Annotation family and nest it. A separate symbol family can be reused across every sprinkler family you ever build and updated in one place.

Inside the annotation family the symbol is a filled region circle with a diameter dimension driving a Symbol D parameter. Two details are worth copying. First, the dimension is a diameter dimension rather than a radius, because a symbol is specified by how wide it reads on the sheet. Second, the filled region type is duplicated before its colour is changed from black to red. Editing a system type in place is how you end up with every filled region in the project turning red.

Back in the sprinkler family, the symbol is loaded and placed with Annotate, Symbol, then aligned to the reference planes so it stays centred when the family flexes. Finally the nested symbol’s own parameter is exposed: Edit Type, associate family parameter on Symbol D, creating a matching family parameter in the host. Type scope is chosen deliberately here, so the symbol reads at a consistent size across the sheet rather than varying instance by instance.

Detail level is what makes the symbol behave

Load the family now and you get both the symbol and the 3D geometry at once, in every view. The fix is Visibility/Graphics Settings on each piece of geometry:

Element	Coarse	Medium	Fine
Nested symbol	Visible	Off	Off
Revolve (head)	Off	Visible	Visible
Extrusion (drop)	Off	Visible	Visible

This is set element by element, and the extrusion has to be caught separately after the first attempt, which illustrates the trap neatly: the setting is per element, not per family, so a new solid added later inherits nothing and shows up in coarse views until you tell it not to.

Once that split is in place the family does the right thing automatically. Ceiling plans set to Coarse show clean symbols. Sections and 3D views set to Medium or Fine show the actual geometry. Nobody has to remember to switch anything.

Coverage circle: a symbolic line with its own subcategory

The last piece of the plan graphic is the coverage indicator. It is drawn with Annotate, Symbolic Line as a circle centred on the family, and because no suitable line type exists, a new subcategory called Coverage Line is created under Object Styles with a red colour and a dashed line pattern, then assigned to the circle.

Symbolic lines are the right tool here rather than model lines: they show in plan at the scale of the view and do not appear in 3D. The circle gets a diameter dimension driving a Coverage D type parameter, kept as a type parameter deliberately because coverage is a property of the sprinkler model, not of where you happened to put it.

For a small sprinkler the build uses a coverage of 3658 mm, which is 12 ft. Treat that as the value used in the demonstration rather than a rule. Coverage depends on the sprinkler model, the hazard classification and the design density, and it is the fire protection engineer who sets it. What the family gives you is a parameter that carries whatever number the engineer specifies, drawn in plan, so a coordination check is a glance instead of a calculation.

Wire in the pipe connector so the family joins a system

A sprinkler that cannot be piped is decoration. A pipe connector is placed at the bottom of the drop with Create, Pipe Connector, and its diameter is associated to a Nominal Dia type parameter which is in turn driven by a formula of nominal radius times two. Chaining the connector to the geometry that way means the connector can never drift out of step with the head.

The connector’s own properties are then set: System Classification is Fire Protection Wet, with Flow Configuration, Flow Direction, Loss Method, Flow and Pressure Drop filled in below it. System Classification is the one that has to be right. It tells Revit which system this connector may join, and a connector left on the wrong classification will simply refuse to connect to the wet riser and give you no useful reason why.

Flow and Pressure Drop are then associated to family parameters, so a small, a standard and a large sprinkler can each carry their own values instead of sharing one.

Use the category parameters, then build real types

Back in Family Types, the built in Sprinklers parameters are now available, and the build fills them in per type: Orifice Size, Temperature Rating, K-Factor, Pressure Class, Coverage and Response. The values shown are a 12.7 mm orifice and a 57 degree temperature rating on the small type, with a larger 25.4 mm orifice on the large type. Types are renamed to Small Sprinkler, Standard Sprinkler and Large Sprinkler.

These are the fields a fire protection engineer will actually look at, and they are the reason the category decision at minute zero mattered. Fill them from the specified product’s datasheet, not with the numbers used in a tutorial.

One neat move closes the loop: Nominal Radius is set to a formula of orifice size divided by two, so the geometry is now driven directly by the catalogue value. Change the orifice size on a type and the head, the drop and the pipe connector all resize together. That is what parametric is supposed to mean, and it is a good test of any family you inherit: change one specification value and see whether anything follows.

When the family throws “the extrusion is too thin”

Adding a second extrusion for the recessed condition, with its Visible parameter associated to the Recessed switch so it only appears when the sprinkler is flush, produces a load time error: an error occurred in the family and was automatically resolved but may require review.

The diagnosis is worth knowing because it works for any family error of this shape. Manage, Select by ID, then Show takes you to the offending element. In this case the cause was a type, not the geometry: the large sprinkler type had its offset and height driver parameters both sitting at zero, which collapsed the extrusion to nothing. Giving those real values cleared it.

The general lesson: when a family that works in the editor fails on load, check every type, not just the active one. Revit regenerates all types on load, and a broken type you have not opened in a week is the usual culprit.

Placing them, and the pipe size that will block you

With the family loaded, sprinklers are copied out at roughly 4.5 m spacing, entered as 4500 mm after a first attempt in the wrong units. The video describes this as the rough field convention of around 15 ft between heads and about half that from walls, and it is worth being precise about what that is: a modelling starting point, not a design. Final spacing comes from the hydraulic calculation and the applicable code for the hazard classification, and it is the fire protection engineer’s number.

Then a genuinely useful gotcha. Right click, Draw Pipe off the connector fails, because the project’s pipe segment has no size matching the 25.4 mm orifice while the pipe wants to start at 32 mm. The fix is Systems, Mechanical Settings, Pipe Settings, Segments and Sizes: find the pipe segment your project uses, add a new size with the nominal diameter you need plus its inner and outer diameters, and the connection then works.

This is one of those errors that reads as a broken family and is actually a project settings gap. If you hand a correct family to a colleague and it will not pipe up on their model, check their mechanical settings before you touch the family.

Where to take this beyond the video

The build produces a working family. Turning it into firm standard content takes a few things the recording does not cover:

Naming and the shared parameter question. Any custom parameter you want to schedule or tag across families should be a shared parameter, drawn from the firm’s shared parameter file, not a family parameter. Family parameters cannot be scheduled or tagged. Decide this before the family is distributed, because retrofitting shared parameters onto placed instances is painful.
Type catalogues. Once you are past three or four types, a type catalogue, a plain text file sitting next to the .rfa, lets you load only the types a project needs instead of carrying all of them. For a product range with a dozen orifice sizes this is the difference between a usable family and a bloated one.
A test project. Keep a small file that hosts the family on a flat ceiling, a sloped ceiling and a soffit, at coarse, medium and fine, in plan, section and 3D. Run every type through it before you release a new version. Most family regressions are visibility regressions and they only show in one view type.
Version control on the .rfa. Families are binary, so put the release date in the filename or keep a changelog beside it. A model that silently gets a new version of a sprinkler family behaves differently and nobody can tell you why.

Common mistakes

Authoring in Generic Models and planning to change the category later. You can change it, but anything already placed does not migrate cleanly, and tags and schedules built against the old category break.
Writing values into formulas instead of into driver parameters. It makes the parameter read only in the project, which usually means the family gets abandoned.
Leaving sketch lines unlocked. The family flexes correctly in the editor and then fails the first time somebody changes a type in a real model.
Expecting a family level visibility setting. There is not one. Every solid you add is a separate decision.
Testing only the active type. Errors on load almost always come from the type you were not looking at.
Treating tutorial values as specification. Coverage, K-factor, temperature rating and spacing come from the product datasheet and the fire protection design, not from a video.

Next steps

Build this one twice. The first pass is a copying exercise, the second is where you notice which decisions were load bearing: the category, the instance versus type calls, the IF formulas with their driver parameters, and the detail level split. Those four ideas transfer to every family you will ever author, whether it is a door, a light fitting or a piece of plant. The parametric window family walkthrough is a good next build, because it exercises the same formula thinking on geometry you already understand.

If you want the structured version of this, with the family editor covered end to end rather than one object at a time, the Revit courses on Archgyan Academy work through family authoring alongside the modelling and documentation workflows around it. Browse the courses and pick the track that matches where you are.