How to Build a Parametric Window Family in Revit

A window is where family authoring stops being about geometry and starts being about arithmetic. A door has a leaf that sits in a rebate and that is more or less that. A window has a frame, a pane that has to stay centred in that frame no matter how deep the frame gets, a sill height that changes per room, and a schedule that will be read by a facade subcontractor. Get the relationships wrong and the pane drifts to one face of the wall the first time somebody types a new frame depth.

That is why the window is the family worth building second, straight after a door. The tools are the same ones you already met. What is new is that some parameters are no longer values you type. They are values Revit calculates, driven by formulas and equality constraints, and once you have written your first working formula the rest of family authoring opens up.

The walkthrough below follows a real recorded build from the Archgyan Revit channel, with links to the exact moment each step happens. If you have not authored a family before, the companion piece on building a parametric door family in Revit covers the sweep and extrusion basics in more detail, and the Revit family creation fundamentals guide covers the theory underneath both.

Start in the Metric Window template and read what it already gives you

The build opens at File, New, Family and picks the Metric Window template. That happens in the first fifteen seconds, and it is the decision that everything else depends on. A family authored in the Window template belongs to the Windows category, so it schedules in the window schedule, accepts window tags, and cuts its own opening in the host wall. Author the same geometry in Generic Model and you get none of that, and there is no later setting that repairs it.

The template is not an empty canvas. It arrives with a short host wall, an opening already cut through it, a set of named reference planes, and parameters already wired up. At 1:08 the exterior elevation shows the supplied Default Sill Height and Height parameters, and Width is there too. Those three are the ones a schedule reads, so do not create your own duplicates of them. Every parameter you add from here should be about the frame and the glazing, not about the size of the hole.

If Metric Window is missing from your template list, that is a content library problem rather than a Revit problem. The metric family templates install separately from the application and are frequently skipped on a fresh machine. Pull them from your Autodesk account rather than substituting something else.

Reference planes before geometry, and dimension from strong to weak

The skeleton comes first. Reference planes get placed, dimensions span them, parameters drive the dimensions, and geometry is locked to the planes. Geometry is never driven directly.

The planes go in from 1:19 in the exterior view, using the RP shortcut. Learning the shortcut rather than hunting for the ribbon button is worth the ten seconds it costs, because you will type it dozens of times in a single family.

Then comes a rule that is easy to hear and easy to forget. At 1:34 the recording pauses on reference strength: selecting one of the template’s planes shows it is the Top reference, while a plane you just drew reports as Weak Reference. Always dimension from the stronger reference to the weaker one. Reference strength is what decides which planes a user can grab and dimension to once the window is placed in a project. Dimension the wrong way round and Revit resolves the constraint against the plane you did not mean, which is one of the quieter reasons a family flexes in the Family Editor and then misbehaves on a project.

The dimension itself is an aligned dimension, DI on the keyboard or Annotate then Aligned Dimension. Do not confuse it with AL, the Align tool, which turns up later for locking sketch lines. Two different tools, two similar shortcuts, and mixing them up wastes a genuinely frustrating ten minutes.

One parameter from several dimensions keeps the frame symmetrical

Four dimensions get placed around the opening, one per side of the frame. At 1:57 all four are selected at once and turned into a single parameter called Frame Thickness, using the Create Parameter button in the ribbon.

Selecting all four before creating the parameter is the whole trick. One parameter driving four dimensions means the frame stays even on all sides forever, whatever value anyone types. Create four separate parameters and you have handed every future user the ability to produce a window with a 50mm head and a 40mm jamb.

The side effect is that all four dimensions collapse to one value the moment the parameter is created, so whatever they read individually before is gone. Set the value you actually want straight afterwards. At 2:19 the value is corrected in Family Types rather than by dragging anything in the view, which is the habit to build: once a dimension is parametric, you change it in Family Types, never in the drawing area.

The frame is a sweep, and this one keeps its bottom line

The frame starts at 2:44 with Create, Sweep. A sweep is two sketches: a path that a profile travels along, and the profile that gets carried around it. The path goes first.

At 2:56 the path is sketched as a rectangle around the opening, then each line is aligned and locked to its reference plane with the AL tool. The sequence matters: select the reference plane first, then the sketch line, then click the padlock that appears. Get it backwards and Revit aligns the plane to the line.

That padlock is the difference between a family that flexes and a family that only looks like it does. An unlocked line sits at the right coordinate today and stays there forever, ignoring the parameter entirely. When somebody tells you their family does not respond to its own parameters, an unclicked padlock is the cause more often than everything else combined.

Note the difference from a door here, because it is easy to copy the wrong habit across. A door frame path has its bottom line deleted, since a door has jambs and a head but no threshold. A window frame path keeps all four sides, because a window has a sill member. Same tool, opposite decision, and the reason is the real object rather than anything about Revit.

The profile is then edited at 3:26, and Revit insists on a view perpendicular to the path, which is why the Left view is the answer. The profile rectangle is locked to reference planes on every side, and then at 3:45 a dimension across it becomes Frame Depth. The view scale gets pushed to 1:10 while this is going on, purely so the dimension text is legible at working zoom. Do it early and stop squinting.

Frame thickness and frame depth are different things

These two get confused constantly, and the confusion reaches drawings.

Frame thickness is the face width you see in elevation, the visible border around the glass.
Frame depth is how far the frame runs through the wall, front to back.

A window schedule that reports one while its column header claims the other will be caught in a submission review, so name them unambiguously the first time and never abbreviate them to the same thing. At 4:07 both get flexed in Family Types and the geometry follows, which is the confirmation that the locks and parameters actually took.

The glazing is an extrusion, and this is where formulas earn their keep

The pane goes in at 4:25 as an extrusion, sketched as a rectangle aligned and locked to the inner reference planes so it always fills the frame opening.

Positioning it through the depth of the wall is the interesting part. The pane should sit centred in the frame, and it should stay centred when the frame depth changes. Typing a number would fix it at today’s frame depth and break it at tomorrow’s. So instead a reference plane is drawn where the centre of the glass belongs, and at 5:06 a parameter is created for it directly in Family Types rather than from a selected dimension. That is a useful thing to know on its own: parameters can be born in the dialog and associated with a dimension afterwards, which is often tidier than the other order.

The parameter is called Glass Position, and its value is not a number. It is a formula: frame depth divided by two. Assign that and the pane recentres itself every single time the frame depth changes, on every type, forever, with nobody having to remember.

Watch the divisor, because the obvious one is wrong

At 5:19 the formula goes in as frame thickness divided by two, and at 5:33 it gets corrected to frame depth divided by two. That correction is worth more than a clean take would have been, because the mistake is the natural one to make and it fails silently.

Frame thickness is measured in elevation, across the face. Frame depth is measured through the wall. The glass is being positioned through the wall, so the depth is the only dimension it can legitimately be half of. Divide the thickness instead and the pane lands somewhere arbitrary near the outer face, geometry that looks plausible in a 3D view and is wrong in every section you cut.

The general rule: when you write a formula, check that the parameter you are dividing is measured along the same axis as the thing you are positioning. Formulas do not error when they are dimensionally sensible and conceptually nonsense.

Centre the pane by equality, not by arithmetic

Glass thickness gets handled a different way, and the contrast is instructive. At 5:39 two further reference planes are drawn either side of the centre plane, made equal, and given one overall dimension which becomes the Glass Thickness parameter. The extrusion faces are then snapped and locked to those two planes.

No formula. The EQ equality constraint does the centring, so the two planes stay symmetrical about the middle automatically and one dimension controls the total. Both approaches keep the glass centred, and it is worth knowing when to reach for which.

	Formula	Equality (EQ) constraint
How it centres	You state the arithmetic explicitly	Revit keeps spacings equal for you
Best for	A position that depends on another named parameter	Splitting one span into equal parts
Visible to the user	Yes, the formula shows in Family Types	No, it lives in the view as an EQ symbol
Fails by	Referencing the wrong parameter	Being deleted or overridden by a later dimension
Used here for	Glass Position, from Frame Depth	Glass Thickness, either side of centre

Formulas are auditable, which is why anything another person needs to understand belongs in one. Equality constraints are quicker and are the right answer for mullion spacing, baluster spacing and glazing bars, where the whole point is that the parts are evenly divided rather than individually calculated.

Assign the material first, then parameterise it

At 6:15 the pane gets a material parameter. Select the extrusion, find the Material row in Properties, and click the small Associate Family Parameter button at the right end of that row. A new parameter called Glass Material is created and the geometry now takes whatever material the parameter points at.

There is a sequencing tip in the recording that is easy to skip past and genuinely useful: assign the real glass material directly to the extrusion first, and only then associate the parameter. Do it in that order and the family itself displays as glass while you author it, which makes a shaded view actually informative. Associate the parameter on a material-less extrusion and you spend the rest of the build looking at grey.

The frame material is handled from 7:34 and shows what to do when the material you want does not exist yet. Open the Asset Browser, search for a timber asset, create a new material, and use the button that replaces the current asset in the editor with the selected one. That is the correct route. Copying an existing material and editing its appearance by hand is how offices end up with fourteen slightly different oaks.

The reason all of this goes through parameters rather than straight onto geometry is reuse. A material applied directly is hard coded into the family file, so every project wanting a different finish needs the family edited and re-saved, and within a year there are five near-identical window families in circulation. With material parameters the family ships neutral and each project sets its own values through Edit Type. The same argument applies to the rest of your standards, which is the subject of our guide to building a Revit project template and office BIM standards.

Build two types and toggle between them

At 6:49 Family Types produces a first real type: 1500 wide by 900 high, frame depth set to suit a 100mm wall, frame thickness around 40 to 50, glass thickness 6mm. Glass Position takes no input at all, because the formula supplies it. That is the moment the formula pays off visibly.

A second, deliberately different type follows at 8:21, and then the two get toggled back and forth. Toggling is not a flourish. It is the test. A family with one type looks perfect right up until somebody duplicates it, and by then the broken constraint is buried under an hour of work. Two obviously different types turn every step into its own check, and the emphasis on obviously matters: if your second type is 10mm wider than the first, a badly locked extrusion will move 10mm and you will not see it.

The professional version is a flex matrix. Before a family leaves your desk, push it to the smallest plausible size, the largest plausible size, and one deliberately absurd value, checking the 3D view, plan and elevation each time.

Loading into a project: no wall, no window

At 8:48 a fresh project is started and the family loaded. Two habits are visible before that. The family is saved first, because loading an unsaved family drops something called Family 2 into the project that nobody can trace to a source file. And the backup count is reduced, since families are small and quickly rebuilt and do not need a deep backup history the way project files do.

At 9:19 the window cannot be placed, and nothing is broken. The Metric Window template produces a wall hosted family, so with no wall in the project there is no valid host. A wall goes in and the window places immediately. That host relationship is a feature, and it is exactly the behaviour a Generic Model version would have thrown away.

From 9:32 the family appears under Families, Windows in the Project Browser. Drag it in and pick a type, or press W, the shortcut for placing a window. At 9:53 Edit Type then Duplicate creates a third type in the project itself at a new width. Types can be born in the project as easily as in the family, which is worth knowing, though a type that only exists in one project will not be there on the next one. Anything you expect to reuse belongs back in the family file.

One naming note. The recording saves the family under a throwaway tutorial name, which is fine for a recording and not fine for an office library. A workable convention is category, then type, then defining dimension, for example WN_Fixed_Glazed_1500x900. No version numbers, no initials, no project codes.

The sill height is hiding under Other, and you can move it

This is the part of the recording most likely to save you a support question, and it comes after the sign off. From 10:37 the sill height gets tracked down.

Open Family Types and Default Sill Height is not with Height and Width where you would look for it. It sits at the bottom of the dialog under the Other group, which is where the Metric Window template puts it. People assume it is missing and start creating a duplicate sill height parameter, which is the worst possible outcome because now the family has two and the schedule reads the wrong one.

The fix is parameter grouping. At 10:53 the parameter is edited and its group changed to Dimensions, and it moves up to sit beside Height and Width where anyone would expect it. Nothing about the geometry changes. What changes is that the next person to open the dialog finds it in two seconds.

Parameter grouping is one of the cheapest quality signals in a family library and one of the most ignored. Dimensions together, Materials and Finishes together, identity data together, and nothing important left in Other. It costs a few seconds per parameter and it is the difference between a library people use and a library people work around. The same instinct applied to views is covered in our notes on Revit view templates and graphic standards.

Once the window is in a project, Default Sill Height sets the value a newly placed instance takes, and each placed window then carries its own sill height you can override where a room needs something different.

Fixed glazing is the base case, deliberately

At 2:29 the scope is stated plainly: this is a fixed pane, with casement and double-hung windows left to later builds. That is the right way to learn it. Every opening type is the same skeleton with more moving parts bolted on.

What gets added as you go up from here:

Opening symbolics. A window that reads correctly in 3D and shows as a blank rectangle in plan is not finished. Casement windows need 2D opening lines in the right subcategory so a view template can control them.
Nested shutters. An openable sash becomes a nested family with its own parameters associated back to the host window, so one type can present as fixed or opening.
Conditional visibility. A yes/no parameter driving the visibility of a sash, a mullion or a glazing bar lets one family cover what would otherwise be four.
Subcategories. Assigning Frame, Glass and Sill to separate subcategories lets Object Styles control each independently, which is what makes elevations read properly at print scale.
Wall closure. The finish layers of the host wall do not wrap into the opening on their own. The wall type needs its layers set to wrap at inserts, and the window family carries a Wall Closure parameter that decides where they stop, which is the build covered in adjusting wall closures in Revit.

Whole-facade glazing is a different problem rather than a bigger window, and it belongs in a curtain wall system. That is covered in our guide to curtain wall systems and facade coordination in Revit.

Common mistakes and what each one looks like

Mistake	How it shows up	Fix
Sketch lines not locked to reference planes	Family looks correct, ignores its parameters	Align tool, click the padlock, verify in every view
Separate parameters per frame side	Head and jamb thicknesses drift apart	Select all four dimensions, then Create Parameter
Dimensioning weak to strong	Constraint resolves against the wrong plane	Always dimension strong reference to weak
Glass Position formula divides frame thickness	Pane sits off centre through the wall	Divide frame depth, the dimension on the same axis
Bottom line deleted from the sweep path	Window has no sill member	Keep all four sides on a window, unlike a door
Material applied to geometry	Family must be edited per project	Associate Family Parameter, group under Materials and Finishes
Duplicate sill height parameter created	Schedule reads the wrong value	Find Default Sill Height under Other and regroup it
Only one family type	Broken constraints surface on the project, not your desk	Two obviously different types from the start

A note on versions

The recording is from an earlier Revit release. Everything it uses, sweep, extrusion, align and lock, Create Parameter, Associate Family Parameter, formulas, EQ constraints and parameter grouping, is unchanged in current versions and the workflow transfers directly. What has moved is peripheral: where the metric template library installs, and the exact arrangement of the Asset Browser. If a button is not where the video shows it, the concept still holds and only the location has shifted.

Where to take this next

Build the window twice. The first time follow along and get a working family. The second time build it from a blank template without the video, because the second attempt is where you find out which parts you understood and which you copied. Then write one formula that is not in this walkthrough, something like a glazing bar count driven by width, and see whether it holds when you flex it.

If you want the full sequence rather than a single build, the complete Revit course on Archgyan works through door and window families in order, from the first reference plane through nested components, conditional visibility and a finished project library. Browse the courses and start with the family authoring section.