What is a Revit family? The three kinds, types and instances, and how families are classified

System families create the basic building elements, walls, floors, roofs, ceilings, stairs, ducts and pipes, and also project settings such as levels, grids, sheets and viewports. They're predefined in Revit and stored in the project or template, not in separate files. You can't create or delete a system family, but you can duplicate one of its types and edit the copy, which is how an office builds its own wall types.

Loadable families are created in external RFA files and loaded into projects. Doors, windows, furniture, plumbing fixtures, lighting, mechanical equipment, and annotation such as tags and title blocks are all loadable. They're the families offices create and edit most.

In-place families are modelled inside the project for one unique element: a reception desk built for one room, a canopy that follows another piece of geometry. Each holds a single type. They're useful once, and a common source of model weight when they're used for things that should have been loadable. Revit LT has no in-place families; its help lists only system and loadable.

A family is the definition. A type is a named variation of it: a single-flush door family with 800 × 2100 and 900 × 2100 types. An instance is one placed copy in the model.

Parameters live at one of two levels. A type parameter changes every instance of that type at once: change the width of the 900 type and every 900 door in the model changes. An instance parameter belongs to one placed element, such as a window's sill height or a door's mark. Deciding which parameter belongs where is most of the design of a good family.

For loadable families with many types, a type catalog lets the user load only the types the project needs, instead of every size the family can make.

Every family belongs to a category, and Revit sets the list, not the user. The category decides which schedule the element appears in, which tag can label it, how Visibility/Graphics shows or hides it, and what it maps to in an IFC export. A light fitting modelled as a Generic Model draws fine on the plan and never appears in the lighting schedule.

Inside a category, subcategories control the linework and visibility of parts of a family, a door's frame, its panel, its swing in plan, so a view can show or hide each one. Categories and subcategories are Revit's own classification. Offices add a layer on top: a naming convention, a folder structure by category, and shared parameters for the data their schedules need. That office layer is usually what Revit library optimization puts right.

A loadable family starts from a family template, an RFT file, chosen by category and hosting: a wall-hosted door, a face-based fixture, free-standing furniture. The category can be changed later in the Family Editor. The hosting can't, so the template choice matters.

A family can contain other families. A door can nest a handle, a casework unit can nest its doors and drawers, and a parameter in the host family can choose which nested type is used. That's how one family covers a range of configurations without modelling each one.

By default a nested family is part of its host and can't be scheduled or tagged on its own. Marked as Shared, it becomes its own element in the project, so the handles, or the light fittings inside a ceiling family, appear in their own schedule.

A family that behaves in a real project:

• Sits in the right category, with the right hosting.
• Splits type and instance parameters by how the product actually varies.
• Flexes: every size it claims to make, it makes without breaking.
• Is light: simple geometry at Coarse detail, no imported CAD, no hidden detail nobody sees.
• Uses parameter names that match the office's schedules.

Building to that bar is covered in custom parametric Revit family creation, and checking a whole model's families against it in Revit model checker.

Autodesk provides a library of loadable families, and manufacturers publish families of their own products. For many elements, that's all an office needs.

Custom families earn their place when the office's details repeat across projects, when a manufacturer's family is too heavy or carries the wrong data, or when the office's standards need parameters no downloaded family has. BIM object creation for manufacturers covers the manufacturer's side. For an office, it's the work our Revit family creation service covers.

If the Autodesk library and the manufacturers' families already cover what your office draws, you don't need custom families, and you don't need us, or anyone like us.