Most of the back-and-forth on a revision job doesn’t come from the markups themselves — it comes from gaps in what shipped alongside them. A drafter who can open the file and immediately understand what changed, why, and where the underlying source lives will turn a revision around in one pass. A drafter working from a flattened PDF, a vague email, and a guess at which sheet is current won’t.

This is the checklist we’d want if we were on the other end of a revision handoff: what to send, how to organize it, and where these jobs most often go sideways before a single line gets drafted.

Start with the source, not just the markup

A markup shows what needs to change. It doesn’t replace the editable source file that has to change. Send the actual DWG (or native file), not just a PDF of the sheet with a cloud drawn on it — and make sure it’s the exact revision the markup was drawn against. A markup made against Rev 2 applied to a Rev 3 file (because someone kept working after the markup went out) creates confusion that’s slower to untangle than the original revision would have been to draft from scratch.

If the source lives across multiple linked files — a title sheet, a general notes sheet, and several plan sheets that all reference the same block or detail — send the whole set, not just the sheet with the cloud on it. A drafter can’t tell that a note on Sheet 3 also needs to match a callout on Sheet 7 unless both sheets are in hand.

PDF, scanned, or digital markups — each has a failure mode

PDF markups (Bluebeam and similar) are usually the cleanest to work from, especially when the underlying PDF was exported with real vector geometry and searchable text rather than a scanned image pasted into a PDF wrapper. Keep markup layers/tags separated by reviewer or by revision round if more than one round is being sent at once — a stack of unlabeled clouds from three different reviewers reads as one undifferentiated mess.

Scanned or photographed redlines are usable, but only if they’re legible: consistent scale, right-side-up, high enough resolution that a dimension string doesn’t dissolve into pixels, and photographed flat rather than at an angle that distorts the sheet. A photo taken at a jobsite in poor light, at an angle, of a sheet with handwriting in the same color as the printed linework, is the single most common cause of a drafter having to guess.

Markups made directly in CAD (revision clouds and text already placed in a working file) are usually fastest to interpret, provided the cloud/revision-block convention matches what the rest of the set already uses. If it doesn’t, say so up front rather than leaving it to be discovered mid-drafting.

Define the actual scope — “per the attached markups” isn’t always enough

A markup shows individual changes. It doesn’t always make clear how far those changes are supposed to reach. Before sending, work out:

  • Which sheets are actually affected — including sheets that reference the changed content (schedules, general notes, detail callouts) but don’t have a cloud drawn on them.
  • Whether the revision is annotation-only (text, labels, dimensions) or also touches geometry/design elements.
  • Whether anything is time-sensitive versus safe to hold for the next round — a mixed batch of “resubmit tomorrow” and “whenever” items sent as one undifferentiated pile usually gets treated as all-urgent or all-not, and one of those guesses will be wrong.

What the drafter needs from your CAD standards

Even a well-marked-up file can stall without the supporting standards it depends on:

  • CAD standards and templates — the layer structure, title block, and any style/template files the set is built from, if the drafter doesn’t already have your current version.
  • Fonts — whether the set uses standard SHX fonts or a custom/licensed TrueType font, since a missing font silently substitutes and can shift line breaks and dimension text across an entire sheet.
  • CTBs/STBs — the exact plot style table the set prints from. Without it, line weights and colors on the delivered PDF won’t match your standard, even if the DWG itself is correct.
  • Xrefs — a list of external references and their expected file paths, or the xrefs bound into the drawing before sending, so nothing shows up as a red “reference not found” box.
  • Images — any raster images (site photos, scanned exhibits, logos) referenced by path rather than embedded, sent alongside the drawing rather than assumed to travel with it.
  • Data shortcuts — if the set uses Civil 3D data shortcuts or data references instead of standard xrefs, the project folder structure they depend on needs to come along, not just the sheet file.

Naming and version control

The single fastest way to lose a day on a revision job is two files both claiming to be “current.” A simple, consistent convention — a revision number in the filename or a controlled revision block in the title, one clearly marked current set, and superseded versions archived rather than left sitting in the same folder — prevents almost all of it. This matters more on a revision job than on new production, because there’s already an earlier version of every file in play.

What usually gets left out

In rough order of how often it causes a delay:

  1. No stated convention for how revision clouds and revision-block numbers should be marked on the updated set.
  2. A markup that references a sheet not included in what was actually sent.
  3. No answer to whether the title block’s revision date/description should be updated as part of this pass.
  4. Ambiguity about whether a note change is text-only or implies a geometry change that wasn’t separately clouded.
  5. No point of contact to ask a quick clarifying question — which turns a two-minute question into a stalled day.

Pre-handoff checklist

  • Current source files (not just a PDF), matched to the exact revision the markup was made against
  • Markups in a legible format — vector PDF preferred, scans flat and high-resolution, in-CAD clouds using your standard convention
  • Scope clarified: which sheets, annotation vs. geometry, priority items flagged
  • CAD standards/templates, fonts, and the correct CTB/STB included or confirmed already on hand
  • Xrefs resolved or bound; data shortcut folder structure included if applicable
  • Referenced images sent alongside the drawing, not assumed to travel with it
  • A clear file-naming/revision convention, with one file marked current
  • A point of contact named for scope questions

Where responsibility stays with your team

Drafting on a revision job is performed against the markups, standards, and source information your team provides. Judging why a change is being made, or whether it’s the correct engineering or surveying response, isn’t part of that — that stays with your responsible licensed professional, both before the markup is sent and after the revised set comes back for review.

Handing off a revision set this way is most of what Drawing Revisions covers day to day — redline incorporation, CAD updates, and the cleanup that goes with them. The same source-file and standards discipline applies to new drafting production too; see CAD Drafting Services if the work in question is a new sheet rather than a revision to an existing one.

If you’re still weighing whether a revision backlog is worth handing to an outside drafter in the first place, When Outside Drawing Revision Support Makes Sense covers that decision. Otherwise, send over your project details and we’ll follow up to scope the work.