Understanding Families: Types, Instances, and Parameters in a Beginner Workflow

Families as the Building Blocks of BIM

In Revit, almost everything you place or create is a family. A family is a definition (rules + geometry + parameters) that can produce many variations. When you place one in the model, you create an instance of that family. This matters because BIM is not just 3D shapes: it is structured data that drives schedules, tags, quantities, and documentation.

Family, Type, Instance (quick mental model)

• Family: the overall category/object definition (e.g., a Door family).
• Type: a named variation within that family (e.g., “D1 900x2100”). Types typically control size/shape and other consistent properties.
• Instance: a placed occurrence in the model (e.g., the door you placed in Room 101). Instances can have unique values like mark, comments, or a flipped hand.

Think of it like this: Family = product line, Type = specific model, Instance = the item installed in a specific location.

Three Family Categories You’ll Use in a Beginner Workflow

1) System Families (built into the project)

System families are created and managed inside the project environment. You don’t load them from files; you configure them through types and settings. Common examples:

• Walls (Basic Wall types with layers)
• Floors (Floor types with structure)
• Roofs (Roof types, slopes, structure)
• Ceilings, Stairs, Railings (also system-based behavior)

Key beginner takeaway: you usually create new types of system families (e.g., a new wall type) rather than “editing geometry” directly.

2) Loadable Families (loaded from .RFA files)

Loadable families are separate files you load into your project. They are typically discrete components:

Continue in our app.

• Listen to the audio with the screen off.
• Earn a certificate upon completion.
• Over 5000 courses for you to explore!

Or continue reading below...

Download the app

• Doors, Windows
• Furniture, Plumbing Fixtures, Lighting Fixtures
• Casework, Specialty Equipment

Loadable families are where you’ll most often encounter well-structured parameters (width, height, materials, identity data) and multiple types inside one family.

3) In-Place Families (project-specific custom geometry)

In-place families are custom components modeled directly in the project as one-off geometry. They can be tempting when you want something “quick,” but for beginners they often cause problems:

• Hard to reuse: they are not easily transferable to other projects.
• Hard to schedule consistently: parameters and categorization are often inconsistent.
• Hard to edit: changes can be fragile and time-consuming.
• Can bloat the model: too many in-place elements reduce maintainability.

Beginner rule: avoid in-place families unless you have a true one-off condition and you understand the documentation impact. Prefer system families (for building elements) and loadable families (for components).

Type vs. Instance Parameters (and How to Decide)

Parameters control data and behavior. The same parameter name can exist as either a type parameter or an instance parameter, and the difference is critical.

Type parameters: change all instances of that type

A type parameter affects every instance that uses that type. Use type parameters for properties that should be consistent across all occurrences of that type.

• Door Width and Door Height are typically type-driven (a “900x2100” door should stay that size everywhere).
• Wall structure (layer thicknesses/materials) is type-driven (a “200mm Concrete Wall” should be consistent).
• Window frame material is often type-driven if the type represents a specific product/spec.

Instance parameters: change only the selected instance

An instance parameter affects only the element you selected. Use instance parameters for properties that vary per occurrence.

• Mark: each door instance typically has a unique mark (D01, D02…).
• Comments: notes that apply to one occurrence.
• Sill Height for windows is often instance-based (same window type, different sill heights in different rooms).
• Offset values (top/bottom offsets) are commonly instance-based.

Rules of thumb: when to create a new type

• Create a new type when the change is a spec change (size, material, construction, rating) that should remain consistent and schedulable as a distinct item.
• Create a new type when you want schedules to show separate rows for different variations (e.g., 900mm door vs 1000mm door).
• Use instance changes when the variation is location-specific and does not represent a different product/spec (e.g., same window type at different sill heights).
• Be cautious about “almost the same” types. If two types differ only because of one accidental tweak, you’ll create schedule clutter and confusion.

Concrete examples (what you should do)

Key Parameter Concepts for Documentation

Good beginner workflows focus on parameters that directly support documentation: tags, schedules, and consistent naming.

Identity Data: what the element “is” in documentation

Many families have an Identity Data group in Properties/Type Properties. Common fields include:

• Type Name: the primary identifier for types (make it meaningful).
• Type Mark (if available): can support type-based tagging/scheduling.
• Model, Manufacturer, URL: useful for product-based workflows (even if you keep them simple at first).
• Comments: can be instance or type depending on family; use carefully.

Beginner best practice: use a clear, consistent type naming pattern so you can read schedules without guessing. Example: D1_Single_900x2100_FD30 or W1_1200x1200_Alum. Keep it short but descriptive.

Materials: what schedules and renderings rely on

Materials can be assigned at the type level or instance level depending on the family. For documentation consistency:

• Prefer type-based materials when the material is part of the specification (e.g., door leaf material).
• Use instance-based materials only when the same type legitimately varies by location (less common for beginners).

When a family exposes a material parameter (often named something like Frame Material or Panel Material), set it intentionally. If you leave materials as “By Category” or default placeholders, schedules and appearance can become unreliable.

Shared parameters (simple awareness for tagging consistency)

You will see two broad kinds of parameters in Revit families: family parameters and shared parameters. You don’t need to author shared parameters from scratch to benefit from them, but you should understand why they matter:

• Shared parameters are designed to be consistent across multiple families and projects, enabling reliable tagging and scheduling across different content sources.
• If a tag or schedule field requires a shared parameter, a similar-looking “regular” family parameter may not work for that tag/schedule setup.

Beginner workflow guidance: when you load families from different sources, check that the parameters you intend to tag (e.g., fire rating, acoustic rating, type mark) are actually available and behaving consistently. If not, standardize by choosing better content rather than patching with in-place workarounds.

Guided Mini-Lab: Duplicate Types, Adjust Dimensions, and Verify in Schedules/Tags

This mini-lab builds a safe habit: duplicate and rename types responsibly, then confirm that documentation updates correctly.

Part A — Duplicate and rename a loadable family type (Door or Window)

1. Select an existing door (or window) instance in the model.
2. In the Properties palette, locate the Type Selector at the top and click Edit Type.
3. In the Type Properties dialog, click Duplicate.
4. Name the new type using a clear convention. Example: D1_Single_1000x2100. Avoid names like “Copy of…” or “Type 2”.
5. Change the key type parameters (commonly Width and Height) to the new values.
6. Click OK to apply.

Checkpoint: only the instances assigned to the new type should change size. If other doors changed unexpectedly, you edited the original type instead of duplicating.

Part B — Decide whether a change should be type or instance

1. Select one of the doors/windows you just modified.
2. In Properties, look for common instance parameters such as Mark, Comments, Sill Height (windows), or offsets.
3. Change Mark to a unique value (e.g., D03) and confirm that only this one instance updates.

Rule reinforcement: if you find yourself changing width/height per occurrence, you probably need more types (or the family is not built with the right parameter strategy).

Part C — Duplicate and rename a system family type (Wall example)

1. Select a wall in the model.
2. Click Edit Type in Properties.
3. Click Duplicate and name it clearly, e.g., W1_200mm_Concrete or W2_150mm_Stud_GWB.
4. Click Structure (Edit) (if available) and adjust layer thickness/materials as required for the new type.
5. Click OK to confirm changes.

Checkpoint: verify that walls using the original type did not change. If they did, you edited the original type.

Part D — Confirm impact in schedules and tags

The goal is to prove that your type naming and parameter choices flow into documentation.

1. Open (or create) a Door Schedule or Window Schedule view.
2. Verify that the new type appears as a distinct entry (commonly by Type or Family and Type field).
3. Check that Type-based fields (e.g., width/height, type name, type comments) are consistent for all instances of that type.
4. Check that Instance-based fields (e.g., Mark) show different values per placed element.
5. In a plan view, place or review a tag (Door Tag/Window Tag). Confirm what it is displaying (often Mark for instance, sometimes Type Mark depending on the tag family).
6. If the tag is not showing what you expect, inspect whether the value is stored as a type or instance parameter, and whether the tag is built to read that parameter.

Mini-lab hygiene: responsible type management

• Duplicate first, then edit: never “test edit” a type that is already used widely.
• Name types immediately: avoid temporary names that end up in schedules.
• Limit type explosion: if two types are identical, delete one and reassign instances.
• Keep identity data meaningful: if you use fields like Type Comments, keep them consistent so schedules remain readable.