Almost everything in a Revit model is an instance of a family. Walls, ducts, light fittings, structural columns, door tags, title blocks — all families. Which kind of family a thing is decides what you can change about it, whether it can be scheduled, whether it travels between projects, and how much it costs the model in performance.
Get the choice right and a model stays fast, schedules cleanly and hands over without argument. Get it wrong and you end up with a project full of one-off geometry that nobody can count, coordinate or reuse.
The Three Kinds of Family
System families
Built into Revit and defined inside the project: walls, floors, roofs, ceilings, ducts, pipes, cable trays. You cannot create a new system family from nothing — you duplicate an existing type and change its parameters. They move between projects only by copying a type or by transferring project standards, never as a file on disk.
Their behaviour is baked in. A wall knows it is a wall; it hosts, joins and cleans up with other walls automatically. That is exactly why you should not model a wall-like object as anything else.
Loadable families
Separate .rfa files created in the Family Editor and loaded into projects: doors, windows, plumbing fixtures, light fittings, mechanical equipment, furniture, annotation symbols, title blocks. This is where the vast majority of real family work happens, and the only category that is properly portable — build once, keep in a library, use on every job.
Each is built from a template that determines its category and hosting behaviour, and the template cannot be swapped later. Choosing the wrong one at the start is the most expensive family mistake there is, because the fix is rebuilding.
In-place families
Geometry modelled directly in the project for one unique situation — an odd bulkhead, a one-off plinth, a piece of feature joinery that exists once on the whole job.
They are the right answer far less often than they are used. Each one is stored separately in the project, they do not schedule or tag reliably as a set, they cannot be reused, and a model with dozens of them gets noticeably slower. The honest test: if this appeared twice, would I regret this? If yes, build a loadable family.
Choosing, Quickly
| Situation | Use | Why |
|---|---|---|
| A new wall build-up | System family type | Walls must behave as walls |
| A specific manufacturer’s AHU | Loadable family | Reusable, schedulable, carries data |
| A one-off curved feature bulkhead | In-place | Genuinely unique to this project |
| A door type that repeats | Loadable family type | Types, not new families, for variants |
| A company title block | Loadable (annotation) | Belongs in the office template |
| A duct fitting not in the library | Loadable family | Must connect and flow properly |
Types Versus Instances
Inside a family, every parameter is either a type parameter or an instance parameter, and the distinction is what makes a model maintainable.
- Type — shared by every element of that type. Change it once and all of them change. Right for nominal size, material, model number, manufacturer.
- Instance — unique to the individual placed element. Right for mounting height, a mark number, a room-by-room value, anything that genuinely varies.
The classic error is making everything an instance parameter “so it’s flexible”. What you get is a model where changing a specification means editing four hundred elements individually, and a schedule that cannot group anything. Flexibility that defeats coordination is not flexibility.
Shared parameters
A parameter created in a family is invisible to schedules and tags outside it unless it is a shared parameter — defined in a shared parameter file and reused across families and projects. If a value has to appear in a schedule, in a tag, or in an IFC export for the client’s asset register, it must be a shared parameter from the beginning.
Where the model feeds a compliance or handover deliverable, the data schema is usually set by the client or by the requirements the building is certified against — the National Construction Code, published by the Australian Building Codes Board, is the usual reference point. Agree the parameter list against that before families are built, not after.
That shared parameter file is a project asset. It belongs under version control with the office template, not on one person’s desktop, because a family built against a different copy of it will not schedule with the rest.
What Makes a Family Good
- Correct category. It determines scheduling, tagging, visibility control and IFC mapping. Wrong category means the element is invisible to the systems that count it.
- Right level of detail. Model what is needed for coordination and documentation, not the manufacturer’s full geometry. Imported high-polygon CAD is the single most common cause of a slow model.
- Constrained and flexed. Dimensions locked to reference planes, then tested through every type before release. A family that breaks when a parameter changes will break on site.
- Real data. Manufacturer, model, performance values, asset data — populated as shared parameters, because the model’s value at handover is the data, not the geometry.
- Sensible connectors. MEP families need connectors of the right system type, correctly placed and with flow set, or the systems will not calculate.
- Named to a convention. Consistent naming is what makes a library usable a year later by someone who did not build it.
Manufacturer Families: Check Before You Load
Free downloadable content is uneven. Before a manufacturer family goes into a live model, check that it is in the right category, that its geometry is modelled rather than imported CAD, that its file size is reasonable, that it has usable parameters instead of hard-coded dimensions, and that it carries no nested families you did not expect.
A single badly built family loaded into a central model becomes everyone’s problem, and removing it later is harder than vetting it now.
Frequently Asked Questions
Can a system family be saved out and reused?
Not as a file. Copy the type into another project or use Transfer Project Standards. The maintainable answer is to hold approved types in the office template.
When should a family be nested?
When a component genuinely repeats inside the parent — a handle used across a door range, for instance. Shared nesting lets the sub-component schedule in its own right. Nesting for convenience, without a plan for how it schedules, is where most family complexity comes from.
Why will my family not tag or schedule?
Almost always one of two things: the family is in the wrong category, or the value you want lives in a family parameter rather than a shared parameter.
Is an in-place family ever the right call?
Yes — for geometry that exists once and will never repeat. The test is repetition, not difficulty.
Family Work as Part of a Model
Family libraries are built once and paid for on every subsequent project — which is why they are worth doing properly rather than accumulating. We build and rationalise families as part of Revit drafting work, including MEP equipment families that have to carry connectors and data through to MEP coordination. If you have a library that has grown unmanageable, tell us what is in it and we will tell you what is worth keeping.