Loadable vs System Families in Revit: A Practical Breakdown

Revit organises every component into family types, and mixing them up is a constant source of frustration: families that will not schedule the way you expect, content that cannot host where you need it, and models that grow fragile and heavy. Understanding the difference between loadable, system, nested and shared families is foundational to building and managing BIM content well.

This article gives a clear, practical breakdown of each family type, how they behave, and when to reach for which, so your Revit content stays clean, light and schedulable.

System families: built into the project

System families are the elements defined by the project itself, walls, floors, ceilings, roofs, stairs. They are not separate files you load in; they live in the project and the template, and you control them through their types and parameters rather than by editing an external family. You cannot create a system family from scratch in a separate file, you duplicate and modify an existing type. They are the building's fabric.

Loadable families: the content you reuse

Loadable families are created in their own external files and loaded into projects, and they are most of the content people think of as "Revit families": doors, windows, furniture, equipment, fixtures, fittings. Because they are external, they can be built, refined and reused across projects, which is exactly why the family creation craft centres on them.

Nested and shared: the advanced layer

More sophisticated content combines families, and this is where shared parameters and nesting matter:

• Loadable: doors, windows, furniture, equipment, the reusable, external content
• System: walls, floors, ceilings, roofs, stairs, the project's fabric
• Nested: families placed inside other families, for example a handle inside a door
• Shared: nested families flagged to schedule and tag independently of their host

A worked example: the door that would not count its handles

A modeler nests a handle family inside a door family so every door gets the right hardware. Then procurement asks for a count of handles, and the schedule shows none, because a plain nested family is invisible to scheduling; it is just geometry inside its host. The fix is to make the nested handle a shared family, at which point Revit can schedule and tag it independently, and the count appears.

This is the classic trip-up that the family types exist to explain: nested gives you the geometry, shared gives you the schedulable data. Knowing the difference turns a frustrating dead end into a two-minute fix.

Use the right type from the start

Trying to force one family type to behave like another, making a system family act loadable, or expecting a nested family to schedule, leads to fragile, confusing content. Choosing the correct type at the outset, system for fabric, loadable for reusable content, nested for sub-components, shared when those sub-components must schedule, keeps a model clean, light and easy to maintain.

Conclusion

Loadable, system, nested and shared families each exist for a reason, and understanding them is foundational to good BIM content. Match the family type to the job, fabric versus reusable content versus schedulable sub-component, and your Revit models stay clean, your schedules stay accurate, and your content stays a pleasure rather than a problem to work with.