CAD drawing review workflow: run it like a pull request

Here is how drawing review works on most teams I've seen: plot to PDF, email it, wait. The markups come back as scanned redlines, a photo of a printout, or a reply-all with "see attached". Someone transcribes the comments back into CAD by hand, usually the most junior person, and whether every comment survived the transcription is anyone's guess. The CAD drawing review workflow I want to describe replaces that relay race with the structure software teams settled on years ago: the pull request. Not the vocabulary, the structure. A proposed change, shown as a diff, discussed in place, approved by the act of merging it.

The unit of review is a branch

Email-based review has a scoping problem before it has anything else: what exactly is being reviewed? The whole sheet? Whatever changed since the last plot? Nobody quite knows, so reviewers re-read everything or skim everything.

A branch fixes the scope. The proposer drafts the change on a branch while the main drawing stays untouched, so "what's under review" has a precise answer: whatever this branch did since it split. Not the sheet, not the project, just the change. That definition is what every later step leans on. (If branches are new to you, the CAD branching and merging pillar explains the mechanics; this post is about the human process on top.)

A CAD drawing review workflow in five steps

1. Branch the change. New retaining wall detail, revised pipe run, whatever the job is. Main stays clean, the branch carries the proposal.

2. Draw it. Nothing new here. It's ordinary drafting, just on the branch.

3. The reviewer reads the diff. BranchCAD's visual diff shows what the branch changed against the drawing it split from: added, modified, removed, right on the geometry. The reviewer isn't hunting for differences between two plots on a light table; the differences are the view. For an outside reviewer, a view-only share link opens the drawing in a browser with no account and no CAD seat, which in practice means the client's engineer actually looks at it.

4. Comments live on the geometry. In BranchCAD, comments anchor to entities. "This offset looks tight" pins to the offset in question and stays pinned as the drawing evolves. Nobody transcribes anything; the discussion happens where the ink is. Compare that with a redline scan, where every comment's location has to be re-derived by whoever does the corrections.

5. Merging is the approval. When the reviewer is satisfied, the branch merges. That's not paperwork after the decision, it is the decision, and the audit trail records who merged what, and when. If both the branch and main touched the same entity in the meantime, the merge flags it rather than letting an approval silently overwrite parallel work. That failure mode has its own post.

What the diff can and can't tell a reviewer

The diff answers "what changed" completely and mechanically. It does not answer "is the change right", and I'd distrust any tool that claims it does. A moved gridline can be a clean, conflict-free change and still break a dimension chain three sheets of context away. Judgment stays with the engineer. The workflow's contribution is that judgment gets spent on the change itself, not on locating it, transcribing comments about it, or figuring out which plot is newer. Those were never engineering. They were logistics wearing engineering's badge.

The paper trail you get for free

Formal issue records and revision certificates don't go away; your QA system still owns those. What changes is how easy they are to write. The audit trail already knows every change, every author, every approval and its timestamp, so assembling "who approved the Rev C boundary change and when" stops being a 40-minute email dig. If your current system's answer to that question is a folder full of files named final_v3, you already know the failure mode.

Branching, merge review, and the advanced diff are Pro-plan features; the pricing page shows the split. If you want to feel the shape of it first, open the editor, branch a drawing, change something, and read your own diff. The reviewer you save may be you, six months from now, trying to remember why the wall moved.