Families, types, and the hierarchy

Almost every "why did Revit do that" question resolves to a misunderstanding of one four-level hierarchy. This page is that hierarchy and its consequences.

The hierarchy

Category        Doors                              ← fixed by Autodesk
  Family        Single-Flush                        ← geometry rules + parameter set
    Type        Single-Flush: 36" x 84"             ← named values
      Instance  the door at grid C-3, sill 0"       ← one placed element

Category

The top-level classification. There are a few hundred, split into model categories (Walls, Doors, Structural Framing) and annotation categories (Door Tags, Dimensions, Text Notes). You cannot create one.

Category determines:

• Visibility and graphics — Object Styles and Visibility/Graphics work per-category.
• What can tag it — a Door Tag reads Doors. Full stop.
• What can schedule it — schedules are created per-category.
• Cut/projection behaviour — how the element draws when the view cuts it.
• Whether it can host — and what it can host.

This is why choosing the wrong category when you author a family is expensive: a casework item modelled as a Generic Model won't appear in a casework schedule and can't take a casework tag.

Subcategories you can create — inside a family, or via Object Styles — giving you independent graphic control over parts of a family (a door's Panel vs. Frame vs. Glass).

Family

A definition within a category. Holds the geometry logic and defines which parameters exist.

Type

A named set of values for that family's type parameters. 36" x 84", Exterior - 8" CMU, 2 HR Rated.

The critical property: all instances of a type share type parameters. Change one, change them all. This is a feature — it's how you update 400 doors at once — and it's the #1 accidental-mass-edit trap.

Always duplicate before modifying. In Edit Type, click Duplicate, rename, then change values. Editing a template's built-in type in place is how you silently alter every wall in the project.

Instance

One placed element. Instance parameters are per-element: Sill Height, Mark, Comments, Base Constraint, Workset, Phase Created.

The three kinds of family

System families

Built from layer definitions, exist only inside a project. Walls, floors, roofs, ceilings, stairs, railings, ramps, curtain systems, ducts, pipes, and all the datum/view elements.

• Cannot be saved to an .rfa.
• Move them between projects with Manage → Transfer Project Standards, or copy an instance and paste.
• Their "structure" is the layer stack in Edit Type → Structure — function, material, thickness, and which layers are core.

Layer function matters. Structure [1], Substrate [2], Thermal/Air [3], Finish [4]/[5], Membrane. Function controls how layers join and wrap at corners and at openings, and which layers count as "core" for dimensioning and room boundaries. Getting functions wrong produces walls that join wrongly and no obvious reason why.

Loadable families

Separate .rfa files, edited in the Family Editor, loaded into projects. Doors, windows, furniture, fixtures, equipment, most annotation, title blocks, tags, profiles.

• The overwhelming majority of what you'll author.
• Can be nested inside other families.
• A nested family can be marked shared, which makes its instances schedulable and taggable independently — useful for a casework family containing scheduled appliances, and unnecessary overhead otherwise.

In-place families

Modelled directly in the project for genuinely unique geometry.

They look like a shortcut and behave like a debt: they bloat the file, they can't be reused, they don't schedule cleanly, and each one is its own family with its own single type. Use them for one-off site-specific geometry and nothing else.

Hosting

Some families require a host:

• Wall-hosted — doors, windows, wall-mounted fixtures. The family contains a void that cuts the host, which is why you never manually cut an opening.
• Ceiling-hosted, floor-hosted, roof-hosted — same idea, different host.
• Face-based — hosts on any surface. More flexible, and the right choice for most equipment families you author.
• Work-plane based — hosts on a level or reference plane rather than geometry.

Delete the host and hosted elements go with it.

Never host across a link. It works until the link is reloaded or the host moves, then it doesn't. Almost every firm standard forbids it.

Consequences worth memorizing

Purging

Manage → Purge Unused removes unused families, types, groups, and materials. Run it before issuing and before measuring file size.

It's aggressive — it removes anything not currently placed, including types you were about to use. Run it, then check that your intended types survived.