Why naming deserves a written rule
Revit sorts almost everything alphabetically: views in the project browser, families in the type selector, line styles in dialogs, parameters in schedules. A good naming convention turns that sorting into organization. A poor one, or no convention at all, means people scroll, guess and create duplicates because they could not find what already existed.
Names also travel. Family and type names appear in schedules and exported data. File names appear in transmittals and common data environments. View names appear on sheets. Inconsistent names leak into deliverables and make coordination harder for everyone downstream.
Principles before patterns
- Most general to most specific. Put the field that groups items first so alphabetical sorting clusters related items.
- Readable by a new hire. If a name needs a lookup table to understand, keep the table short or use words.
- Consistent separators. Choose one separator for fields and use it everywhere. Avoid characters that cause problems in file systems or exports.
- No meaning in position alone. Fields should be recognizable, not just "the third token".
- Stable over time. Avoid including things that change, such as a person's initials or a temporary status, in names that are hard to rename.
Separators, characters and length
Pick a field separator and stick to it. A hyphen between fields and spaces or underscores within a field is common, but the choice matters less than consistency. Some guidance:
- Avoid characters that are invalid or awkward in file names and URLs, such as slashes, colons, asterisks, question marks, quotes and angle brackets. Some of these are also restricted in Revit names.
- Decide how to handle case. Upper case for codes and sentence case for descriptions reads well.
- Keep names short enough to read in a narrow project browser. If a name needs a scroll bar, it is too long.
- Use leading zeros for numbers that should sort numerically, so 02 sorts before 10.
Project file names
File naming is often set by contract or by the project's information standard. If your project follows ISO 19650, the national annex or the appointing party's information standard will usually define fields such as project, originator, volume or system, level or location, type, role and number. Follow it exactly when it applies.
For internal files without such a requirement, a simpler pattern works:
[Project number]-[Discipline]-[Building or zone]-[Description] 2401-ARCH-BLDG A-Central model
Keep version numbers and dates out of central model names. Revit and your document management system track versions; putting them in names leads to broken links when files are renamed.
Views
Views are where naming conventions pay off daily. Two decisions help most.
First, separate working views from sheet views. Many firms prefix working views or organize them under a browser parameter, so the views placed on sheets stay clean. Working views can then be cleaned up before issue without risk.
Second, put the level or location first for plans, so views sort by floor:
[Level]-[View purpose]-[Area] 02-Floor Plan-Overall 02-Reflected Ceiling-Wing B 00-Site Plan-Landscape
For sections and elevations, start with a direction or grid reference. For details and drafting views, use the library classification; see the detail library guide.
Remember that the title on a sheet can differ from the view name. Revit has a "Title on Sheet" property, so internal names can be precise while sheet titles stay presentable.
Sheets
Sheet numbers usually follow a national or firm standard, often a discipline letter followed by a series and sequence number. Sheet names should describe content plainly. Rules worth writing down:
- The sheet number pattern, including discipline letters and series.
- How to number placeholder sheets for sheets not yet drawn.
- Case and abbreviations allowed in sheet names.
- How revisions are recorded, which belongs in revision fields, not names.
Families and types
Family and type names surface in schedules, tags and exported data, so they deserve particular care.
Family names should say what the object is, starting with the most general term:
[Category or function]-[Description]-[Variant] Door-Single Flush-Vision Panel Furniture-Desk-Rectangular Detail Item-Fixing-Masonry Tie
Type names should express the property that differentiates types, often dimensions or a specification reference:
915 x 2135 Width 1800
Avoid repeating the family name in the type name; Revit already shows them together. Decide on units and dimension order, such as width before height, and apply it everywhere.
For manufacturer families, decide whether the manufacturer name belongs in the family name, the type name or only in a parameter. Putting it in a parameter keeps names generic and lets the product change without renaming.
System types: walls, floors, roofs and annotation
System families like walls, floors and roofs benefit from names that describe their build-up:
[Function]-[Primary material]-[Overall thickness]-[Note] Ext-Masonry Cavity-350-Insulated Int-Stud Partition-125-Acoustic
For annotation, name line styles, text types and filled region types by purpose and appearance, such as "Detail - Heavy", "Note - Standard" or "Insulation - Batt". These are the types a CAD layer mapping points to, so clear names make the mapping easier to read and review.
Parameters
Shared and project parameters need names that are unique, clear and stable, because renaming them later can disrupt schedules, tags and exports. A short prefix that identifies your firm's parameters helps distinguish them from built-in ones and from parameters in manufacturer content. Write a sentence describing each parameter's purpose in your parameter register, and include its data type and the categories it applies to.
Worksets and links
If you use worksharing, keep workset names few and functional: links, shared levels and grids, building shell, interiors and so on. Name linked models with the same file naming rule as everything else, so it is obvious which discipline and version is loaded.
Abbreviations
Abbreviations save space and cost clarity. Keep an approved list, short enough to remember, and do not allow ad hoc abbreviations. If an abbreviation is not on the list, spell the word out. Include the list in your standard and in the template's documentation.
Codes or words?
Every naming convention balances codes, which are short and sortable, against words, which are readable. Codes work well where a recognized classification already exists and people use it daily, such as discipline letters or sheet series. Words work better where users are browsing, such as family names in the type selector, view names in the project browser and detail names in a library.
A useful compromise is a short code at the start for sorting, followed by words for meaning: "WALL-Masonry Cavity-Head". The code groups related items; the words tell a new team member what they are looking at. If you find yourself creating a lookup table with dozens of codes, it is usually a sign that words would serve better.
Whichever balance you choose, test it with people who did not write the convention. Ask a recent hire to find five items using only the project browser. Where they hesitate, the convention needs work.
Adopting a convention without chaos
- Start with the template. Rename types, views and families in the template first, so new projects start right.
- Do not rename live projects mid-stage unless the benefit is clear. Renaming can break references in schedules, filters, view templates and external tools.
- Publish examples, not just rules. A page of good and bad examples teaches faster than a specification.
- Check at milestones. A short naming review before issue catches drift while it is still small.
- Version the convention. Record changes so older projects can be understood.
Naming checklist
- Field order from general to specific, with one separator.
- Allowed characters, case and length rules.
- File naming aligned with contract or information standard where required.
- View, sheet, family, type and system type patterns with examples.
- Annotation types named by purpose.
- Parameter naming with a firm prefix and a register.
- Approved abbreviation list.
- Change process and version history.
Naming is one part of a wider standard. For a right-sized approach to the rest, see BIM standards for small firms, or explore the Nova strategy packs for templates that help assign ownership of standards like this one.