Revit documentation workflow for architecture practices
Sheets display the model. The production work is views, annotation, schedules and issue-ready organisation — after the model can support those drawings.
Published 24 August 2026 · 3 min read
Revit documentation is the work of turning an agreed model state into a drawing set the office can issue. Plans, elevations, sections, schedules and sheets still have to be created, cropped, annotated and checked. That is production. It is easy to underestimate, because it looks like placing views on a titleblock.
Model readiness
The drawings will show whatever is in the model. If levels are wrong, if openings are missing, or if the envelope is still a placeholder, the sheets will record that. Documentation cannot repair an incomplete model. The brief should say which model state is being documented, and which views are required from it.
Views before sheets
A sheet is a container. The useful work is deciding which views are needed, applying the right graphics, and keeping them consistent. Plans, elevations and sections in Revit are cuts of the model, not a second independent drawing set. Detail views and callouts only help if the model — or the 2D work placed in those views — actually contains the information.
Plans, elevations and sections
These are the core architectural views. They need the correct level or cut, a crop that matches the office convention, and a view template so lineweights and visibility do not drift from sheet to sheet. Duplicate views with slightly different names are a common source of wasted time later.
Schedules
Schedules report what is in the model. They do not create missing doors, windows or rooms. If a door schedule is required, the doors have to exist as Revit elements with the parameters the schedule reads. Asking for a schedule from an under-modelled file produces an empty or misleading table.
Annotation
Dimensions, tags, text and keys belong to the views. Office conventions for annotation should be sent with the brief — or the quotation should state that annotation will follow a stated default. Inconsistent tags and mixed text styles are a documentation problem, not a modelling one, but they still have to be resolved before issue.
Sheets, issue preparation and checking
Views are placed on a titleblock, numbered and named to the office drawing system. Revision clouds and issue notes follow the practice’s convention if that convention is supplied. Checking is still the practice’s responsibility: coordination against the appointment, completeness of the issue, and any professional sign-off.
Production problems that waste time
- Duplicated views with near-identical names
- View templates that were applied once and then overridden on every sheet
- A Project Browser that cannot be searched because naming is inconsistent
- Missing levels or grids that only appear when a section is cut
- Sheet numbering that does not match the office drawing system
- Annotation styles that change from view to view
Questions
The drawings will show whatever is in the model. Scope should say which views are required and from which model state.
No. Producing agreed views and sheets is not the same as checking, issuing or taking professional responsibility for the design.