Revit Family Creation Fundamentals: A Practical Guide for BIM Professionals

Families are the building blocks of every Revit model. Walls, doors, windows, furniture, structural members, annotation tags, and title blocks are all families. When you understand how families are built, you stop being a person who only places content from a library and you become someone who can shape the model to fit the project. That shift is one of the clearest dividing lines between a Revit user and a BIM professional.

This guide covers the fundamentals of authoring loadable families: the family types, picking the right template, building a reliable skeleton with reference planes, applying constraints, driving geometry with parameters and formulas, nesting families, and the mistakes that trip up most people. The goal is not to make you memorize every dialog box. It is to give you a mental model that holds up across any family you need to build.

The three family types, and why it matters

Before you open the Family Editor, you need to know which of the three family types you are dealing with. Choosing the wrong one is the most common early mistake.

Family type	Created in	Edited where	Typical use
System family	Defined in the project template	Project, via type properties	Walls, floors, roofs, ceilings, pipes, ducts
Loadable family	Family Editor (.rfa)	Standalone file, then loaded	Doors, windows, furniture, equipment, tags
In-place family	Inside the project	Project only	One-off geometry unique to a single project

System families cannot be created from scratch in a separate file. You build new types by duplicating an existing one and changing its parameters. You cannot save a wall to your hard drive as a reusable file the way you can with a door.

Loadable families are the ones you author in the Family Editor and save as .rfa files. This is where most of your family creation work happens, and it is the focus of this guide.

In-place families are modeled directly in the project for geometry that is genuinely unique and will never be reused, such as a custom reception desk shaped to a specific lobby. Use them sparingly. They bloat the model, cannot be scheduled cleanly across projects, and tempt people into modeling things that should have been loadable families.

The rule of thumb: if you will use it more than once, or on more than one project, build a loadable family.

Start with the right template

Every loadable family begins from a family template file (.rft). The template sets the family category, the default reference planes, the cut behavior, and how the family hosts itself. Picking the right template saves hours, because changing category later is painful and sometimes impossible.

Go to File, New, Family and you will see templates such as Generic Model, Door, Window, Furniture, Casework, and Specialty Equipment. The two decisions baked into the template are:

1. Category. This controls scheduling, visibility, tags, and how the family behaves. A door scheduled as a door needs the Door template, not Generic Model.
2. Host behavior. Some templates are wall-based, floor-based, ceiling-based, face-based, or non-hosted (free-standing). A wall-based light fixture cuts an opening in its host wall. A non-hosted family floats freely.

Choose hosting deliberately. Wall-hosted families are convenient because they move and delete with the wall, but they break if someone deletes the host or swaps the wall for a different system. Face-based families are the most flexible for equipment that might sit on a wall, floor, or ceiling. When in doubt for free-standing content like furniture, start non-hosted.

If you genuinely need custom geometry with no special category behavior, the Generic Model template is the safe default. You can change a Generic Model’s category later in Family Category and Parameters, which is far easier than trying to undo a wrong hosting choice.

Reference planes are the skeleton

This is the single most important habit in family creation: build the skeleton before the geometry.

Reference planes are invisible construction lines that define where geometry lives and how it moves. You constrain your solids to reference planes, you put dimensions between reference planes, and you attach parameters to those dimensions. When a parameter changes, the reference planes move, and the geometry follows because it is locked to them.

A clean workflow looks like this:

1. Open the relevant views (usually a plan and an elevation).
2. Draw reference planes for the key faces and centerlines of the object.
3. Name the important reference planes in their properties so you can find them later.
4. Add dimensions between reference planes.
5. Label those dimensions with parameters.
6. Flex the family (change the parameter values) to confirm the skeleton moves correctly.
7. Only then model the geometry and lock it to the planes.

People who skip the skeleton and model the box first almost always end up with families that distort, that will not flex, or that snap back to the wrong size. Geometry locked directly to other geometry is fragile. Geometry locked to a named, dimensioned reference plane is predictable.

Set the Origin thoughtfully too. The two reference planes marked as “Defines Origin” control the insertion point of the family. A door should insert at the center of its opening. A column should insert at its center. If the insertion point is in the wrong place, every placed instance will be annoying to position.

Constraints lock the design intent

A constraint is a relationship Revit must keep true. The two you use most are the lock (the small padlock that appears on dimensions and alignments) and the equality constraint (the EQ symbol that keeps spacing equal).

When you align geometry to a reference plane and click the padlock to lock it, you are telling Revit “this face always stays on this plane.” When the plane moves, the face moves. When you place an equality constraint across a row of reference planes, Revit keeps the gaps equal even as the overall dimension changes, which is how you build evenly spaced mullions, shelves, or balusters that adapt to any width.

A few discipline points that prevent grief later:

• Do not over-constrain. If you lock the same geometry to two conflicting things, Revit throws “constraints are not satisfied” errors when you flex. Constrain each degree of freedom once.
• Constrain to reference planes, not to model edges. Edges of solids are not stable references. Named reference planes are.
• Test every constraint by flexing. A constraint you never tested is a constraint you cannot trust.

Parameters: instance versus type

Parameters are the controls that make a family parametric. The first decision for any parameter is whether it should be a type parameter or an instance parameter.

	Type parameter	Instance parameter
Scope	Affects every instance of that type	Affects only the one placed instance
Change in project	Edit type, all instances update	Edit one instance independently
Good for	Standard door width, fixed shelf depth	Mounting height, a sill that varies per opening
Shown in Properties	Type Properties dialog	Properties palette when selected

If a property is the same for all instances of a type, make it a type parameter. A “600mm wide door” type should always be 600mm wide. If a property legitimately varies per placement, make it an instance parameter. Mounting height of a wall-mounted device often varies, so it belongs on the instance.

There is also a distinction between family parameters and shared parameters. Family parameters live inside the family and work for flexing geometry, but they cannot be scheduled across the project or tagged. Shared parameters are stored in an external text file and can be scheduled and tagged. If a value needs to appear in a schedule or on a tag (a fire rating, a model number, a manufacturer), it must be a shared parameter. This is one of the most common reasons a family “will not show up in my schedule,” and it is covered in depth alongside scheduling workflows.

Name parameters clearly and group them sensibly (Dimensions, Identity Data, Construction). A family with parameters named “Width,” “Height,” and “Frame Depth” is usable by anyone. A family full of “Length1,” “Length2,” “Param7” is a liability.

Formulas and parametric flex

Formulas let one parameter drive another, which is where families become genuinely intelligent rather than just adjustable.

Common patterns:

• Derived dimensions. Set Glass Width = Opening Width - (2 * Frame Width) so the glass always fits the frame, no matter the door size.
• Half values. Half Width = Width / 2 to position something on a centerline.
• Conditional logic. Sill Height = if(Height > 2100mm, 0mm, 900mm) to change behavior based on a threshold.
• Yes/No control. Drive a visibility parameter with Show Vision Panel = Height > 2000mm so a feature appears only when it makes sense.

A few rules that keep formulas working:

• Formula syntax is case sensitive. Width and width are different parameters.
• Functions like if, and, or, not, round, and sqrt are available. Comparison results feed Yes/No parameters.
• Keep units consistent. Revit handles unit conversion, but mixing a length and a number in the wrong place is a frequent source of errors.

Build formulas incrementally and flex after each one. A family with ten chained formulas added all at once is almost impossible to debug. Add, flex, confirm, repeat.

Nested and shared families

A nested family is a family loaded inside another family. You might build a door handle once, then nest it into several door families. This keeps your content modular and consistent. Update the handle once and reload it everywhere.

By default, a nested family is treated as a single fixed component. Two upgrades make nesting powerful:

1. Shared nested families. If you tick “Shared” in the nested family’s category settings, the nested family schedules and tags as its own element inside the project, even though it lives within a host family. This is how furniture sets, or a casework run made of individual cabinets, report their individual pieces.
2. Parameter association. You can link a parameter in the host family to a parameter in the nested family using the small grey button next to the parameter value. Now changing the host’s “Handle Height” drives the nested handle. This is how you flex nested geometry from the parent.

Nesting also supports type swapping through family type parameters, which let a user pick which nested family loads into a slot, for example swapping between three handle styles from a dropdown in the host. Powerful, but introduce it only once the basics are solid.

Categories, subcategories, and visibility

How a family draws on a sheet matters as much as how it flexes. Two controls handle this.

Subcategories let you assign different parts of a family to different line weights and styles. A window family might have subcategories for Frame, Glass, and Sill, each controlled independently through Object Styles in the project. Without subcategories, the whole family draws with one line weight, which looks flat and unprofessional on drawings.

Visibility settings on each solid control where it appears. Select a solid, open Visibility/Graphics Overrides, and you can set whether it shows in Plan, Elevation, when Cut, and at Coarse, Medium, or Fine detail. A good family shows simplified geometry at Coarse for performance and full detail at Fine. A light fixture might show only a symbolic line in plan at Coarse but full 3D geometry at Fine.

Use symbolic lines and model lines correctly. Symbolic lines always face the viewer and are for 2D representation, such as the swing arc of a door in plan. Model lines exist in 3D space. Mixing them up produces families that look wrong in section or that swing the wrong way.

Test the family before you load it

Flexing is the discipline of changing parameter values and watching the family respond, inside the Family Editor, before it ever touches a project.

A practical test routine:

1. In Family Types, create two or three test types at the extremes (smallest, largest, and a mid value).
2. Switch between them and watch the geometry. Nothing should distort, detach, or throw a constraint error.
3. Set values to deliberately unreasonable extremes to see where it breaks, then add limits or formulas to prevent invalid input.
4. Check every relevant view (plan, elevation, section, 3D) and every detail level.

If a family flexes cleanly through its full range in the editor, it will behave in the project. If you only test it after loading, you will be deleting and reloading repeatedly, and any instances already placed may misbehave.

Common family creation mistakes

These are the issues that come up again and again, especially for people transitioning into BIM from a drafting background.

• Modeling geometry before the skeleton. The result is a family that cannot flex. Build reference planes and constraints first, every time.
• Locking geometry to geometry. Faces locked to other faces are fragile. Lock to named reference planes instead.
• Wrong template or category. A piece of equipment built as a Generic Model will not schedule or tag like equipment. Choose the category before you start, or reset it early.
• Over-constraining. Conflicting constraints cause “constraints not satisfied” errors. Constrain each degree of freedom exactly once.
• Family parameters where shared parameters are needed. If it must appear in a schedule or tag, it has to be a shared parameter.
• No subcategories. Everything draws with one line weight and the family looks amateur on sheets.
• Bloated geometry. Excessive detail, imported CAD, or unpurged content makes a heavy family that slows every project it enters. Model only what reads at the scales you draw.
• Bad insertion point. An origin in the wrong place makes every placed instance frustrating to position.
• Never flexing. Untested families are the source of most “this family is broken” support tickets.

A repeatable family workflow

Pull all of it together into a sequence you can run for any new family:

1. Plan the parameters. Decide what must flex and what must schedule before you open Revit.
2. Pick the template. Correct category and hosting from the start.
3. Set the origin. Define the insertion point with the origin reference planes.
4. Build the skeleton. Reference planes, named, for every key face and centerline.
5. Dimension and label. Add dimensions between planes and assign parameters.
6. Flex the skeleton. Confirm the planes move correctly with no geometry yet.
7. Model and lock. Add solids and lock them to the reference planes.
8. Add formulas. Drive derived dimensions and conditional behavior, flexing after each.
9. Set subcategories and visibility. Control line weights and detail levels.
10. Nest if needed. Add and associate nested families.
11. Flex the full family. Test the extremes across all views and detail levels.
12. Purge and save. Remove unused content, give it a clear name following your office standard, and save.

Follow that order and your families will be predictable, lightweight, and reusable, which is exactly what a project team needs from shared content.

Where to go next

Family creation rewards practice more than reading. Start with something simple like a parametric shelf or a basic table, build the skeleton first, and flex it until it never breaks. Then move up to a window with a frame, glass, and a sill on subcategories. Once nesting and shared parameters feel natural, you can build almost anything a project demands.

If you want a structured path through Revit and the wider coordination workflows that real firms run, the BIM courses on Archgyan are built and taught by a working BIM Coordinator, with everything in one subscription. You can explore the full catalogue at academy.archgyan.com/courses and start turning family creation into a skill you reach for every day.