Revit Revisions and the Drawing Issue Workflow: Getting a Set Out the Door

A model can be perfectly coordinated and still produce a bad issue. The clashes are resolved, the schedules balance, the federated review signed off cleanly, and then the set goes out with revision clouds from three months ago still visible, two sheets carrying the wrong revision letter, and a register that lists a drawing nobody actually exported.

That is the gap most BIM teams underestimate. Coordination is a model activity and it gets attention. Issuing is a documentation activity, it happens under deadline pressure, and in most firms it is owned by whoever happens to be free on the day. The result is a set that is technically correct and contractually messy.

This guide covers the issue side of the workflow: how Revit revisions actually behave, how to number and schedule them so the titleblock tells the truth, how the drawing register relates to what left the office, what status and suitability codes are doing on the sheet, and the checks that stop a bad set before it reaches a client inbox.

Why the issue is a contractual event, not a print job

The moment a drawing leaves the office it becomes a record. Somebody will build from it, price from it, or argue about it. Two years later, when a subcontractor claims they built to the drawing they were given, the only thing that settles it is the issue record: which revision of which sheet went to which party on which date, and what changed between that revision and the one before it.

Revit does not manage that on its own. It manages the revision metadata on the sheet. Everything around it, the register, the transmittal, the archive of what was actually sent, sits in your common data environment and your document control process. Understanding where the boundary falls is the first step, because a lot of teams assume Revit is handling a step it has never handled.

The practical version: Revit answers “what does this sheet say about itself”. Your CDE answers “what did we send, to whom, and when”. Both have to agree, and keeping them in agreement is the actual job.

Three objects, not one: revisions, clouds and tags

Most revision problems trace back to treating these as a single thing. They are three separate objects with different scopes.

The revision is a project-wide record. It lives in the Sheet Issues and Revisions dialog and has a sequence, a date, a description, a numbering setting, an issued state, and a visibility setting. Creating a revision changes nothing visible in the model. It only creates the row that everything else refers to.

The revision cloud is an annotation element that marks a changed area and points at one revision. It has a scope that trips people up constantly: a cloud drawn inside a view belongs to that view and appears wherever that view is placed. A cloud drawn directly on a sheet belongs only to that sheet. Both are legitimate, they mean different things, and mixing them without a rule is how the same change ends up clouded twice on one sheet and not at all on another.

The revision tag is a separate annotation that labels a cloud with its revision number. It is a loadable family, it is not automatic, and a cloud without a tag reads as an unexplained bubble.

The rule worth writing into your standards is simple. If the change is in the model or in a view’s annotation, cloud it in the view so it follows the view everywhere it is placed. If the change is sheet-specific, a view swapped out, a note added on the sheet, a titleblock correction, cloud it on the sheet.

Numbering: per project, per sheet, or neither

Each revision row carries its own numbering setting, and this single choice shapes how the whole set reads.

Numbering	What the reader sees	Use when
Per project	Every sheet touched by revision 3 shows revision 3, whether or not it was in revisions 1 and 2	The set is issued as a set and the client tracks issues, not sheets
Per sheet	Each sheet counts its own revisions, so a sheet revised once shows revision 1 even at project revision 5	Sheets are issued individually and each drawing carries its own history
None	The revision exists and can be scheduled, but no number is assigned	Superseded or administrative rows you want recorded but not numbered

Per project is the common default on building projects and it is usually the right call, because most clients and contractors think in issue events. Per sheet is defensible on packages that get released drawing by drawing, but it produces the confusing situation where two sheets in the same envelope carry different revision numbers for the same issue date. Decide once, at project setup, and record it in the BIM execution plan. Changing it halfway through renumbers history and creates a set nobody can reconcile against what was already sent.

The sequence column is separate from the number and controls the order rows appear. Revit uses it internally for ordering; it is not what the reader sees. Alphanumeric sequences are worth configuring up front if your firm issues preliminary revisions as P01, P02 and contractual revisions as C01 onward, which is common practice on projects following ISO 19650 in the UK and much of Europe. Check the project’s information standard rather than assuming, because the convention varies by region and by client.

Revision schedules, and why the titleblock lies

The revision block on a titleblock is not a static table. It is a revision schedule authored inside the titleblock family, and its behaviour is set by the schedule’s own filter and its field list. When a titleblock shows the wrong revisions, the cause is almost always one of four things.

The filter is showing all project revisions rather than only those on the sheet. The schedule can be set either way. Showing everything means a sheet untouched since revision 1 displays revisions 2 through 6 as well, which is misleading on a drawing that has not changed.

The revision has no cloud on that sheet. A revision reaches a sheet’s schedule because a cloud belonging to it is visible there, or because it has been explicitly added through the sheet’s Revisions on Sheet setting. That second route matters more than people realise. It is how you record an issue on a sheet that genuinely did not change, for example when a whole package is re-issued for tender and every sheet needs to carry the new revision.

The revision’s visibility is set to hide the tag and cloud. Hiding the graphics does not remove the revision from the schedule. That is the intended behaviour, and it is the mechanism behind the standard housekeeping step described in the next section.

The titleblock is using the wrong parameters for the current revision box. Sheets carry read-only parameters for the current revision, its date and its description, derived from the latest revision applicable to that sheet. If the titleblock’s “Rev” box is a text field somebody types into, it will drift from the schedule within one issue cycle. Make it a parameter, not typing.

Issuing a revision: what the lock does and does not do

Ticking the Issued box on a revision is the deliberate act that closes it. It locks the clouds assigned to that revision so they cannot be edited, deleted or reassigned, and it freezes the row’s fields. That is genuinely useful: it stops somebody dragging a historical cloud around next month and quietly rewriting what was issued.

What it does not do is equally worth knowing. It does not stop the model changing. It does not stop views being swapped on sheets. It does not archive anything, and it does not export anything. A sheet whose revision 3 is locked can still have its plan view edited beyond recognition the next morning, and the only record that revision 3 ever looked different is the PDF you exported and filed.

That is the whole reason the exported set, not the model, is the record. The Revit file tells you the current state. The issued PDF in the CDE tells you what you sent. Anyone who treats the live model as the archive will eventually be unable to answer a straightforward question about what a drawing looked like at tender.

The standard housekeeping sequence after an issue is: mark the revision Issued, then set its visibility so the clouds and tags no longer display. The revision line stays in the schedule, the history stays intact, and the next revision’s clouds are the only ones the reader sees. Skipping the second half is why some sets accumulate six generations of clouds until the drawing is unreadable.

Sheet numbering and view naming that survive an issue

Revision control sits on top of a sheet numbering system, and a weak one undermines everything above it. Sheet numbers are effectively permanent once a set has been issued. Renumbering after issue means the contractor’s sheet A-201 and yours are different drawings, which is a genuinely expensive kind of confusion.

Three rules cover most of it. Number by discipline and drawing type with enough spare range that a new section sheet does not force a renumber. Never reuse a retired number, even years later on the same project. And keep the sheet name stable, because it appears on the register, the transmittal and the titleblock, and a reworded name reads as a different drawing to anyone tracking it in a spreadsheet.

View naming and browser organisation matter here for a practical reason rather than a tidiness one: at issue time somebody has to confirm that every sheet holds the intended views at the intended revision, and that is far quicker when the browser groups by sheet status. Our guide to building a Revit project template covers where these conventions live so each project inherits them instead of reinventing them, and the sheets and views workflow guide covers the day to day organisation.

The drawing register, and how it drifts from the model

A drawing register is the list of every drawing in the package with its current revision, status, date and issue history. Every project has one, and on most projects it is a spreadsheet maintained separately from the model. That separation is where the errors breed.

You have two realistic options.

Schedule it from Revit. A sheet list scheduling sheet number, name, current revision, current revision date and any custom status parameters is generated from the actual sheets and cannot list a drawing that does not exist. It can be placed on a cover sheet, so the set carries its own index, and it can be exported for the register. The limitation is that it only knows about this model, so a package spanning several models needs assembling.

Maintain it in the CDE or a document control system. Some platforms generate the register from what has actually been uploaded and issued, which means it reflects transmitted reality rather than model intent. That is closer to the contractual truth, but it needs disciplined uploading or it silently under-reports.

The failure mode in both directions is the same: a drawing exists in one place and not the other. A sheet added late and exported but never added to the register. A register row for a drawing that got cancelled and deleted. The fix is not a better tool, it is a single reconciliation step before every issue, comparing the exported file list against the register line by line. It takes ten minutes and catches the errors that cost days.

Status and suitability codes: what the set says about itself

A revision number tells you which version. It does not tell you what the drawing may be used for, and that is a different and more dangerous question. A drawing shared for coordination is not a drawing approved for construction, and a set that does not say which it is will eventually be built from when it should not have been.

Under ISO 19650 this is handled by status or suitability codes applied to each information container at issue. Codes in the S range signal work in progress and various kinds of sharing, from coordination through information, review and comment, and stage approval. Codes in the A range signal that content is authorised and accepted. Separate ranges cover issues made for specific downstream purposes such as costing, tender and manufacture. The exact code list belongs to the project’s information standard, which is set in the exchange information requirements and confirmed in the BIM execution plan, so read it rather than importing the one you used last time.

Two practical points. The code belongs on the drawing itself, not only in the file metadata, because the drawing gets printed and forwarded and separated from its metadata within a day. And the code must be an explicit field somebody sets, not something inferred from the revision prefix, because inference is exactly how a preliminary drawing gets treated as approved.

Our guide to the common data environment covers the four information states and the approval workflow these codes sit inside, so this post does not repeat it.

Transmittals, issue records and superseded drawings

The transmittal is the record of the send: what was issued, to whom, in what format, on what date, and under which status. Most CDE platforms generate it automatically when you publish, which is one of the stronger arguments for issuing through the CDE rather than by email attachment.

Three habits separate teams whose records hold up from teams whose records do not.

Issue the whole envelope, not loose files. A transmittal covering a defined package is auditable. Six separate emails with attachments are not, and reconstructing them a year later is genuinely painful.

Supersede explicitly. When revision 4 goes out, revision 3 is superseded and should be marked as such in the CDE, not deleted. Deleting removes your ability to answer what the recipient was working from. Leaving it live and unmarked means somebody downloads it and builds from it.

Keep the archive outside the model. Every issue produces a folder of exported files that never changes again. That folder, plus the transmittal, is the record. Some teams also archive a detached copy of the model at major issues, which is worth doing at tender and at construction issue even though it is not worth doing weekly.

Model coordination issues are a separate track from drawing revisions and should not be conflated with them. If you are managing those, the BCF issue workflow is the openBIM route for that side of the work.

Export standards: PDF and DWG that arrive readable

The export step is where a good set gets degraded, usually through inconsistency rather than error.

File naming. Exported filenames should be generated from sheet parameters rather than typed. Recent Revit versions let you build the filename from a rule combining project number, sheet number, sheet name and current revision, which removes an entire class of manual error and makes the register reconciliation trivial. A consistent name also lets the recipient sort a folder of two hundred drawings meaningfully. Our post on BIM naming conventions and file standards covers the container naming side in detail.

PDF settings. Fix the paper sizes, the raster and vector quality, and whether you export one file per sheet or one combined file. One file per sheet is the default expectation on most projects because it lets the recipient reissue a single drawing without splitting a bundle. Set it once as a saved export setup so it does not vary by whoever is exporting.

DWG exports. These need more care than PDFs because they are editable. Use a defined layer mapping standard rather than Revit’s defaults, decide deliberately whether views on sheets and links are exported as external references or bound, and check whether the recipient wants sheets or models. Sending a model DWG when the request was for sheets, or vice versa, wastes a day of somebody’s time.

Check the output, not the settings. Open a sample of the exported PDFs and look at them. Not all of them, but a plan, a section, a detail sheet and the cover. Fonts substituting, a view showing an unexpected phase, a titleblock field blank: these appear in the output and not in the dialog.

The pre-issue QA checklist

This runs after the model is clean and before anything is exported. Model health and standards compliance are a separate discipline covered in our model quality assurance workflow. This checklist is specifically about the issue.

1. The revision row is correct. Date, description and numbering match what the transmittal will say. The description is written for the recipient, not for you.
2. Every changed sheet carries a cloud, and every clouded change is real. Walk the change log against the set. Changes made but not clouded are the more expensive error of the two.
3. Prior-revision clouds are hidden. Every earlier revision has been issued and its visibility turned off. Only the current revision’s clouds display.
4. Sheets re-issued without changes are ticked onto the revision. Any drawing going out in this envelope that has no cloud still needs the revision recorded on it.
5. Every cloud has a tag. Untagged clouds are ambiguous on a printed sheet.
6. The titleblock reads correctly on a sample of sheets. Current revision, date and status. Check a sheet that changed and a sheet that did not.
7. The status or suitability code is set and correct for this issue. Not carried over from the previous one.
8. The sheet list matches the register. Line by line, both directions.
9. The exported file count matches the sheet count. A silent export failure on one sheet is common and easy to miss.
10. A sample of exported files opens and reads correctly.
11. The revision is marked Issued in the model. Do this after export, not before, so a late correction does not require unlocking.

Who owns the issue

On larger projects there is a document controller, and the split is clean: they own the register, the transmittal, the CDE upload and the distribution list, and the BIM coordinator owns everything inside the model, which means the revisions, clouds, titleblock behaviour and export setups.

On smaller projects there is no document controller, and the work does not disappear, it lands on the BIM coordinator or the project architect. The common failure is assuming somebody else has it. Name a person in the BIM execution plan, even if that person also does three other jobs, because an unowned issue process degrades quietly and nobody notices until an audit.

The one thing that should never be shared is the act of marking revisions Issued and exporting. One person, one sequence, one time. Two people exporting the same package in parallel produces two slightly different sets, and working out which one the client received is a bad afternoon.

Common mistakes

• Clouding on the view when the change is sheet-specific, or the reverse. Produces duplicated or missing clouds across the set.
• Leaving old clouds visible. By revision 5 the drawing is unreadable, and the reader cannot tell what actually changed this time.
• Re-issuing without creating a new revision. The set goes out looking identical to the last one and the recipient files it as a duplicate.
• Renumbering sheets after issue. Guarantees a mismatch with everything already sent.
• Typing the revision into the titleblock. It drifts from the schedule within one cycle, and the drawing then contradicts itself.
• Switching numbering from per project to per sheet mid-project. Rewrites the visible history and makes older transmittals unreconcilable.
• Treating the model as the archive. The model moves on. Only the exported set records what was issued.
• Deleting superseded drawings from the CDE. Removes the evidence of what the recipient was working from.
• Setting the status code by habit. A preliminary drawing carrying an approved code is the most consequential error on this list.
• Exporting under deadline with no checklist. Every item above exists because somebody skipped it once.

How to start

If your issue process is currently informal, three sessions will fix most of it.

First, write the rules down. One page. Numbering per project or per sheet, the cloud scope rule, the status codes this project uses, who issues, and the export naming pattern. Put it in the BIM execution plan where consultants can see it, because they are issuing into the same set.

Second, fix the titleblock. Confirm the revision schedule filter is showing only revisions on the sheet, that the current revision box uses the sheet parameter rather than typed text, and that the status field exists as a parameter. This is an hour in the family editor and it removes the most common source of contradictory drawings. Push it into the office template so the next project inherits the fix.

Third, run the checklist on your next issue and time it. It will feel slow the first time and take perhaps forty minutes on a mid-sized package. By the third issue it takes fifteen, and it will have caught at least one error that would otherwise have gone out. That is the entire argument for it.

Revision control is not glamorous work and nobody gets promoted for a clean transmittal. But it is the layer where a well-coordinated model turns into something a contractor can build from without ringing you to ask which drawing is current. Getting it right is a large part of what separates a modeller from a coordinator.

If you want to build the underlying Revit and coordination skills this kind of documentation ownership rests on, the courses at Archgyan Academy cover the workflows firms actually run, taught by a working BIM Coordinator, all in one subscription. If you are working out where documentation and standards ownership sits as a career step, our BIM career roadmap covers how the modeller, coordinator and manager roles differ in practice.