Build a Revit Title Block Family from Scratch

Every drawing that leaves a Revit project leaves through a title block. It carries the project number, the sheet number, the revision, who drew it, who checked it, the client, the architect, the logo. If any of that is typed by hand on every sheet, it will be wrong on at least one of them by the time the set is issued, and the drawing register will disagree with the sheets it lists.

The fix is not discipline. It is a title block family that reads those values from the project, so the sheet number on the drawing is the sheet number in the browser, the revision on the drawing is the revision that was actually issued, and the client name is typed once in Project Information and never again. Most offices inherit a title block someone built years ago and nobody wants to open. This post rebuilds one from a blank A1 so you understand every piece of it, and can build one for your own practice or fix the one you inherited.

The walkthrough follows the recording below, which builds the whole family and tests it in a live project. The sections that go beyond what the video shows are marked as such.

Start from the title block template and check the units

A title block is a family, so it starts in the Family Editor, not in a project. The family is created from the A1 metric title block template, which gives you a blank sheet boundary at the right paper size and puts the family in the Title Blocks category automatically. Do not try to build a title block from a Generic Annotation or Generic Model template. The category is what lets a sheet accept the family, and it is set by the template you start from.

Before drawing a single line, check the family units. The video works in millimetres, and A1 is 841 by 594 mm. That check takes five seconds and saves you from discovering, after an hour of placing labels, that your offsets were in the wrong unit and nothing sits where you thought it did.

If your office issues more than one sheet size, you will repeat this build per size. Each paper size is a separate family, because the boundary lines are fixed geometry, not a parameter. The rest of the content can be copied between them, which is a good reason to build the first one carefully.

The first geometry is a rectangle inset from the sheet edge. The rectangle tool is used with an offset of 10 mm, clicked from one corner of the sheet, and here is the detail worth watching: pressing the space bar before the second click flips which side of the boundary the offset falls on. Without that toggle the offset rectangle sits outside the sheet instead of inside it. It is a small thing that catches almost everyone the first time.

Then comes the sidebar, the vertical strip down the right-hand edge that will carry all the sheet information. A single line is drawn with an offset of 100 mm from the border, again using the space bar to toggle the offset side. That 100 mm strip is what the rest of the family fills.

A note on the offset itself. In the family editor you are drawing at real paper scale. The 100 mm sidebar in the family is 100 mm on the printed A1 sheet, a point the video makes explicitly later on. Whatever your office standard says the information panel width should be, that is the number you type here, with no scale factor to remember.

Text notes versus labels: the distinction the whole family rests on

This is the concept that separates a title block that works from one that only looks like it does, and the video pauses on it deliberately.

A text note is static. It is the word “Project number” printed on the sheet, and it says the same thing on every sheet, forever. You add it with Create, then Text. A label is dynamic. It is a placeholder that shows the value of a parameter, so it reads “A101” on one sheet and “A102” on the next without anyone touching the family. You add it with Create, then Label. The headings in the sidebar are text notes. The values under them are labels. Mixing these up gives you a title block where somebody has to open the family and retype the sheet number by hand every time, which is exactly the problem you were trying to remove.

The video builds the headings first. A text note reading “Project number” is placed in the sidebar, then its type is edited: duplicated and renamed to a 3 mm type, with the Text Size set to 3 mm. That heading is then copied twice and renamed to “Drawing number” and “Revision”. Two lines are drawn to box the three headings into cells.

The duplicate-then-set-size step is one to watch closely because it comes back later in the video as a trap. Duplicating a text type and giving it a new name does not change its size. You have to change the Text Size value as well. A type called “3 mm” that still prints at 8 mm is a lie your future colleagues will inherit.

Project number, sheet number and revision as labels

With the headings placed, the first label goes underneath “Project number”. In the Edit Label dialog you pick a parameter from the list on the left, add it to the label parameters on the right, and give it a sample value. The sample value is only what you see in the family editor; in a project the real value takes over. As with the text note, the label type is duplicated to a 3 mm type and its size set to 3 mm.

The second label, under “Drawing number”, is the Sheet Number parameter, with A101 as the sample value. The third, under “Revision”, uses the Current Revision parameter. Sheet Number and Current Revision are system parameters. Revit knows what they mean, populates them from the sheet and from the revision tools, and you do not need to create anything for them to work.

That last point deserves a moment. A lot of the information a title block carries already exists as a system parameter: Sheet Number, Sheet Name, Project Number, Project Name, Client Name, Project Address, Project Status, Current Revision, Scale, Date/Time Stamp, Drawn By, Checked By, Designed By, Approved By. Before you create any parameter of your own, scroll the list in the Edit Label dialog. If it is there, use it. Custom parameters cost you a shared parameter file and a project parameter, which the second half of the video shows in full.

Load it into a project early and test it

Rather than build the entire family blind, the video stops after three labels and loads the family into a new project. This is a habit worth copying. Family editor sample values tell you almost nothing about how a title block behaves; a real sheet in a real project tells you everything.

Before loading, the family is saved with the maximum backups set to one. Then in the project, a new sheet is created from the Project Browser and the new title block is picked as its type. The sheet appears with the three labels populated.

Two behaviours are demonstrated here. First, the values that come from type parameters can be edited straight away, so the project number can be changed to a real value and the sheet number to something like A101 or B101. Second, and less obvious, the revision does not show until a revision is assigned to the sheet: edit “Revisions on Sheet” in the sheet properties and tick the revision, and the label fills in. Additional revisions are added under View, then Revisions, and whichever ones are ticked for a sheet drive what the label shows.

Load early, find the problem, go back to the family. It is a loop you will run four or five times on a title block build, and it is faster than building everything and debugging it all at once.

Scale, date, drawn by, checked by

Back in the family, the video nudges the existing elements into position with Shift plus the arrow keys, copies a line and a heading, and adds four more headings: Scale, Date, Drawn by, Checked. Then the labels to match.

The Scale label uses the system Scale parameter. It is worth knowing what this one does before you rely on it: it reports the scale of the viewport on the sheet. When a Level 1 plan at 1:100 is dropped onto the sheet later in the video, the label reads 1:100 automatically. If a sheet carries views at more than one scale, this label reports “As indicated”, which is why offices that issue mixed-scale sheets often show scale in the view title instead and leave the title block scale for single-view sheets.

The Date label uses the Date/Time Stamp parameter, and the sample value has the time portion removed so only the date shows. Then Drawn By and Checked By, both system parameters, placed under their headings and set to 3 mm.

There is a practical detail in this section that has nothing to do with parameters and everything to do with printed drawings: the label’s extents are dragged in so the text box does not overlap into the neighbouring cell. Labels have a bounding width, and if it crosses a line the value can appear to run into the next field or wrap unexpectedly. Size the extents to the cell.

Loaded back into the project, the date, drawing number, author and checker all populate, and the author and checker are typed in as initials. Those two are instance parameters on the sheet, so each sheet can carry different initials, which is what you want.

Sheet name, address, and why real-world scale matters

The next block is the larger text: a “Title” heading with the Sheet Name parameter beneath it, given a new 6 mm label type rather than the 3 mm used for the data fields. Sheet names are the thing people read first on a drawing, and they need to be legible from across a table.

Right here the video makes the point about scale that every family builder needs to internalise: a title block family is drawn at 1:1 paper scale. The 100 mm sidebar prints as 100 mm on an A1 sheet. A 6 mm label prints at 6 mm. There is no view scale to account for, which is different from every annotation you place inside a plan or section, where text size is paper size and the model behind it is scaled. If you have only ever built model families, this is the mental switch to make.

Project Address follows as another system-parameter label at 6 mm. Then the video reaches for an Architect field and finds nothing to reach for.

When Revit has no parameter for you: the shared Architect parameter

There is no “Architect” among the system parameters. Client Name exists, Project Address exists, but the design firm’s own name does not, and this is where a custom parameter becomes necessary. The video creates it as a shared parameter, and this section is the most important ten seconds of the recording for anyone working in a team.

Why shared, and not a family parameter? Because a family parameter lives inside the title block and nothing else can see it. It cannot be scheduled and it cannot be set from the project. A shared parameter is defined once in an external text file with a unique identity, and any family, project or schedule that references that same file sees the same parameter. The video is direct about the team implication: the project must use the same shared parameter file as the family. Agree it with your BIM manager, or if you are the BIM manager, put the file somewhere that will not be deleted and that the whole project uses for its full life. In the recording it is created in a folder alongside the project files, as part of the common data environment.

Inside the file, a group called “Sheets” is created and a parameter called “Architect” is added to it, as a Text parameter under the Common discipline. Back in the Edit Label dialog the new parameter appears, is added to the label, and the Architect field is in place. The video then spells out the payoff: because the parameter is shared, once the family is loaded and the parameter is brought into the project, Architect can be a column in a sheet schedule like any system field.

Client Name follows as a system label at 6 mm, so the sidebar now reads Title, Project Address, Architect, Client.

Logo, address text, status, and the revision schedule

Two static pieces come next. The logo is placed with Insert, then Image, dropped in at whatever size the file arrives and then scaled down in place. Then the office address is added as a text note at a new 2 mm type, and this is where the earlier warning is repeated on screen: duplicating a text type and renaming it does not change the height. Set the Text Size after you rename.

Address text is a text note, not a label, for a sensible reason: it is the office’s own address, it never changes per project, and there is no system parameter for it. Anything that is genuinely constant across every sheet in every project belongs as text. Anything that varies belongs as a label.

A Status heading and a Project Status label follow at 6 mm, so a set can be marked Preliminary, Tender, Construction and so on from Project Information rather than by editing sheets.

Then the revision schedule. This is a schedule that lives inside the title block family and lists every revision ticked for the sheet it sits on. It is created from View, then Revision Schedule, with the fields set to Revision Number, Revision Description, Issued By and Revision Date, and Revision Sequence left out. The column headings are renamed to shorter labels so they fit the sidebar. Back in the sheet view the schedule is dragged into place, nudged, and its column widths adjusted with the drag handles. The schedule title is switched off under the Appearance tab of the schedule properties, because the sidebar already has a Revision heading and a second one wastes height.

The revision schedule in the title block is what makes revision tracking honest. You do not type revision rows into the sheet. You issue a revision under View, then Revisions, tick it on the sheets it applies to, and every one of those sheets grows a row. Nothing to forget, nothing to retype.

Notes, reload, and multiple revisions on a sheet

A Notes block is the last thing added: a heading and a body text placeholder that will appear on every sheet, for the standard notes an office wants on every drawing. Then the family is loaded into the project again, overwriting the existing version, and the sheet fills with all the new fields.

Adding a second revision under View, then Revisions, then ticking it in the sheet’s Revisions on Sheet dialog, adds a second row to the revision schedule and updates the current revision label. That is the whole loop working end to end.

The video also does something quietly useful at this point: it creates a couple more sheets and renames one, and shows that the site address entered once appears on every sheet, as does the architect field. Values that come from Project Information are project-wide by design. Values that are per-sheet, like sheet name and drawn by, are not. If you have ever wondered why changing the client name on one sheet changed it everywhere, this is why, and it is correct.

Project parameters: making the shared parameter editable per project

The Architect field showed on every sheet, but where does its value get set? The shared parameter exists in the family, but the project does not yet know about it. The video adds it under Manage, then Project Parameters: Add, then Shared Parameter, select the file, pick Architect. It is set as an Instance parameter and assigned to the Sheets category. Once that is done the Architect field appears in the sheet properties, and typing a name there populates the title block.

The video closes on the general rule, and it is the rule to remember: create the parameter as shared, use it in the family, add it to the project as a project parameter, and it appears in the title block and in schedules. Any field your office needs that Revit does not ship with follows the same four steps.

One judgement call the video makes and you may make differently: Architect is set as an instance parameter on sheets, which means it can vary per sheet. On most projects there is one architect and it would be more convenient as a project-wide value. If you want that behaviour, assign the project parameter to Project Information instead of Sheets, and it behaves like Client Name. If you have joint venture sets where the sheet author differs by discipline, instance on Sheets is the right call.

Beyond the video: office standards for a title block that lasts

The recording builds a working title block. It does not, because a fifteen-minute tutorial cannot, cover the decisions that make one usable across a practice for years. None of the following is demonstrated in the video; it is what a BIM lead adds on top.

Line weights and line styles. The border, the sidebar and the cell dividers were drawn with default lines. In an office family, put the border on a heavier line style and the cell dividers on a lighter one, and make sure the family’s line styles map onto the project’s line weights. A title block whose border prints as thin as its cell lines looks unfinished.

One family per size, consistent content. Build the A1 first, then create the A0, A2 and A3 families from it. Keep the sidebar width and the label types identical so a set that mixes sizes still reads as one set. Name the families and their types to your naming convention; the BIM naming conventions post covers what that should look like.

Put it in the template. A title block that lives on a network drive gets loaded by hand and forked by whoever loads it. Load the finished families into the office project template so every new project starts with them, alongside the shared parameter file location. The Revit project template guide sets out where title blocks sit in that template.

Sheet Issue Date versus Date/Time Stamp. The video uses Date/Time Stamp, which is convenient because it needs no input. It shows the date the sheet was last printed or exported, not the date it was issued. Many offices prefer the Sheet Issue Date system parameter, which is set deliberately per sheet and does not change every time someone prints a check set. Choose one and write down which.

Sheet size on the sheet. Add a small text note with the paper size in the corner. It sounds trivial until a set is printed at the wrong size and nobody can tell from the drawing.

Test with a schedule. Once the shared parameters are in, build a sheet list schedule with Sheet Number, Sheet Name, Current Revision and Architect as columns. If any of them come up blank, the parameter is not wired the way you thought. The shared parameters and schedules post goes deeper on that side of it.

Common mistakes

Every one of these has cost someone an afternoon.

Building from the wrong template. A Generic Annotation family will not appear in the title block list when you create a sheet. Start from a title block template.
Using text notes where a label was needed. The sheet number is a label. The project number is a label. If it can change, it is a label.
Duplicating a text type without changing the size. The type is renamed “3 mm” and still prints at 8 mm. Rename, then set Text Size.
Forgetting the space bar on offset. The offset rectangle lands outside the sheet boundary. Toggle the side before the second click.
A family parameter where a shared parameter was needed. It shows on the sheet and cannot be scheduled or set from the project. Delete it and rebuild it as shared.
A shared parameter file on somebody’s desktop. The file goes missing when they leave, and every project that used it loses the link. Keep it in the CDE and agree the location with the team.
Label extents crossing cell lines. Values wrap or overrun into the next field. Drag the extents to fit the cell.
Not loading and testing until the end. Sample values in the family editor hide most problems. Load after every few labels.
Editing the title block inside a live project without saving the family. The next load from the library overwrites the fix. Edit the family file, then reload.

Where to take this next

Once the family exists, the sheet workflow around it gets a lot lighter. Creating the sheets themselves is covered in the older guide to creating a sheet in Revit, and if you have a drawing register in Excel, creating every sheet from that register with Dynamo is the natural next automation, since the graph needs exactly the title block family you have just built. Managing what happens to the revision fields at issue time is its own topic, and the revisions and drawing issue workflow post picks up where the revision schedule in this family leaves off.

If family creation in general is new to you, the Revit family creation fundamentals post covers the editor concepts this build leaned on: reference planes, types, parameters and loading. And for the full path from an empty template to an issued set, with title blocks, sheets, schedules and revisions taught in the order a project actually needs them, see The Complete Revit Course.