TL;DR: Construction drawing software is built for people who review drawings professionally. Bluebeam names "architects, engineers, contractors and owners" as its audience and never mentions homeowner review. On a custom home, the person approving the plans is a homeowner who will never own a seat. That gap is where revisions get approved twice and built once.
Ask a custom builder where their last change order came from and a surprising number trace back to the same thing. Somebody approved a drawing. Then the drawing changed. Then nobody was sure which version the approval attached to.
It usually surfaces at framing, when the client walks the house and asks why the window in the back bedroom moved. It did not move. They approved revision 2 in an email thread, the architect issued revision 3 the following week, and the field set was built from revision 3. Everyone is telling the truth and somebody is paying for it.
That failure has a name in our threat model, and it is the reason this part of the platform exists.
Who does drawing software actually assume is doing the reviewing?
Professionals. That is the honest answer, and it explains most of the friction.
Bluebeam's drawing and document management workflow names its audience directly: "architects, engineers, contractors and owners," plus subcontractors, MEP, and specialty trades. Reviewed 2026-07-27, its workflow page makes no mention of homeowner or client review anywhere.
That is not an oversight. It is a product decision that fits the market it serves. On a commercial project every reviewer is a professional with a seat, a login, and a working understanding of what slip sheeting is.
On a custom home, the most consequential reviewer is a couple who have never opened a PDF markup tool and never will. They are not going to learn one to approve the plans for their own house. So the review happens in email, in a text thread, or across a kitchen table with a printed set, and the record of what was approved is whatever anyone can find later.
What actually goes wrong when a client approves a drawing?
They approve a revision that is no longer current, and nothing stops them.
This is the highest-severity finding in our own threat model for the feature, dated 2026-07-11 and written before any of the review UI was built. Listed as T2, "client approves a stale (superseded) revision," rated High. The scenario is mundane. A review link goes out on Tuesday. The architect uploads a corrected sheet on Thursday. The client opens Tuesday's email on Friday and clicks approve.
Without a guard, the system now records an approval against a superseded sheet, and it looks authoritative because it has a name and a timestamp on it.
The fix is in the approval path itself. When a client approves through a review link, the server re-reads the version being approved and refuses the approval unless that version is still flagged current. A stale sheet returns a precondition failure rather than an approval. Reviews already in an approved or superseded state are rejected outright, and the status flip is predicated on the current status, so two people clicking approve at the same moment produce one approval and one conflict, not two.
An approval that cannot attach to a stale sheet is a different object from an email that says "looks good."
How do you let a homeowner mark up a drawing without teaching them CAD?
By shipping five markup types instead of fifty, and by storing them in a way that survives the viewer.
A markup on a drawing is one of: a cloud, a text note, an arrow, a highlight, or a measurement. Measurement is staff-only because it needs scale calibration, which is exactly the kind of thing a homeowner should never be asked to set up. The remaining four are what a client actually needs to say "this closet, not that one."
The part that matters more is invisible. Markup geometry is stored in normalized page space, coordinates from 0 to 1, rather than pixels. A cloud drawn around a window on a laptop lands on the same window when the builder opens it on a phone, at a different zoom, against a different rasterization of the same PDF. Pixel coordinates break the moment anything about the render changes. Normalized coordinates do not.
Comments are threaded separately from markups and can carry an optional page pin, so a conversation can be anchored to a spot on a sheet without requiring a drawn shape to hang it on.
What happens to the markups when a new revision comes in?
They carry forward automatically, and the open reviews on that drawing are superseded in the same transaction.
This is the piece I would point to if someone asked what this does that a shared folder does not. When a new version of a drawing is added, the system copies the published markups onto the new revision and flips any open review on that document to superseded, both inside one database transaction. Either all of it happens or none of it does.
The practical effect is that a change request survives the revision it was made against. The client clouded a wall on revision 2 and asked for the pantry to be deeper. Revision 3 arrives. That cloud is sitting on revision 3, where anyone can check whether the pantry actually got deeper, instead of being stranded on a sheet nobody opens again.
The threat model lists the failure this prevents as T5: a new revision leaving stale markups and open reviews inconsistent. Without the carry-forward, every revision quietly resets the conversation.
Why are there two ways into the same review?
Because a homeowner and a structural consultant need different front doors to the same state machine.
A review moves through shared, then changes requested, then revised, then shared again, and finally approved, with superseded available as a terminal state. That machine is identical no matter who is reviewing.
What differs is the door. The token channel sends an emailed link that opens the review without an account, which is how you get a response from an engineer or an interior designer who is never going to be a user in your system. The portal channel routes the same review to a homeowner already logged into their own project.
One state machine, two doors. The alternative, which is what most builders live with, is a consultant review that happens in email and a client review that happens somewhere else, with no shared record of which one is holding up the set.
Approvals through the two channels record differently on purpose. A portal approval ties to the homeowner's user record. A token approval leaves that field empty and captures the signer by name, because the person on the other end of an emailed link is whoever opened it.
How do you keep internal notes off the client's screen?
By making publication an explicit act rather than a default.
Every markup carries a published flag that starts false. Staff can mark up a drawing privately, argue about it internally, and correct it before any of it becomes client-visible. The read that serves the client review returns only published markups. Unpublished ones are visible on the internal read exclusively to the staff member who drew them.
The threat model rates the leak of staff-private markups to a client as High severity, listed as I1, which is the correct rating. A superintendent's note about a trade's workmanship reaching the homeowner's screen is not a UI bug. It is a relationship problem you cannot take back.
The token response is scoped to exactly one reviewed version, that review's comment thread, and the published markups on that version. Not the document's other revisions, not other clients' comments, not the rest of the job's drawings.
What makes a drawing approval hold up six months later?
The evidence stamped next to it, not the approval itself.
When a client approves, the system records the signer's name and title, the signature image, the time of signing, and the moment they consented to sign electronically. The signer's IP address and user agent are captured server-side rather than accepted from the browser. Signature uploads are checked at the byte level to confirm they are actually PNG images, and markup geometry payloads are capped so an oversized or forged payload cannot be pushed through the public endpoint.
The threat model files this under repudiation, R1: the signer denies approving. The mitigation is that there is a record with enough detail to make the denial unpersuasive.
Approval also stamps the document row itself with the approved version, the approval time, and the signer name, so downstream features read one authoritative answer to "which revision is approved" rather than each deriving it independently.
How does the builder know a review is stuck?
Because the system tracks the last thing the client did, not just what the builder sent.
Each review stores a due date, when a reminder was last sent, and a timestamp of the most recent client-side activity, which updates on a view, a comment, a change request, or an approval. That last field sorts the staff review inbox, which means the reviews surface in order of who has gone quiet rather than in the order they were created.
A review shared eleven days ago that the client opened once and never returned to looks different from one shared yesterday. Those are different problems and they need different phone calls.
Where does an approved drawing actually go?
Into one record that everything downstream reads, instead of into a folder somebody has to interpret.
Drawings live in a job-scoped folder tree with the categories a custom build actually produces: plans, permits, contracts, selections, closeout. Each document carries auto-incrementing versions, one flagged current, each with its own revision notes explaining what changed. The version number is unique per document at the database level, so two people uploading at once cannot both create a revision 4.
When an approval lands, it stamps the document itself with the approved version, the approval time, and the signer's name. That stamp is the single source of truth for every feature that needs to know which set is live. A superseded revision shows a banner rather than silently looking authoritative. Takeoffs pin to the approved revision instead of to whatever was most recently uploaded.
This is the difference that shows up in an argument. "Which drawing did they approve" has one answer that the system produces the same way every time, rather than four people reconstructing it from three inboxes.
It also means the approval and the selection sit on the same job. A homeowner approving a kitchen layout and a homeowner approving the cabinet package are two decisions that used to live in unrelated systems, and now hang off the same project record with the same kind of evidence attached.
What does this not do?
Three things worth being straight about.
It is not a CAD tool and it is not trying to be. There is no drafting, no layer management, no sheet-set automation.
Bluebeam is better at professional markup depth, and it is not close. Its batch slip sheeting automatically matches new revisions to current sheets while preserving markups, its permissions are project- and role-based, and it maintains a live record of who viewed, edited, or approved each document across a full AEC team. If your reviewers are all professionals with seats, that is the mature answer and this is not a reason to switch.
Client-side measurement is deliberately absent. Measurement markups require scale calibration, and a mis-calibrated measurement in a homeowner's hands produces confident wrong numbers, which is worse than no numbers.
The wedge here is narrow and specific: the reviewer who has no seat, no training, and the most at stake. That reader is a homeowner, and every tool above was built for someone else.
That pattern repeats across the trades we configure. The concrete cutting setup tracks blade life by the foot, and the coatings setup treats a test cut as a record, for the same reason drawing review treats a stale sheet as a hard stop: the object that decides whether the job goes right should be a first-class thing in the software, not a note attached to something else.
Frequently Asked Questions
Can consultants who aren't our clients use the emailed link safely?
Yes. The link carries a 64-character token, the public endpoints are IP rate-limited, and the tenant is derived from the review record rather than from anything in the request, so a token cannot be pointed at another company's documents. The response is scoped to the single version under review.
What happens if two people approve at the same time?
One approval wins. The status change is predicated on the review's current status, so the second attempt updates zero rows and returns a conflict rather than overwriting the first approval.
Do we have to use the homeowner portal, or can we run everything through emailed links?
Either. The channel is per review. Builders who have not rolled out portal access to clients yet run entirely on tokens and lose nothing except the tie between an approval and a known user account.
Does this replace our document storage?
It sits on top of it. Drawings live in a job-scoped folder tree with auto-incrementing versions, so the review loop reads from the same versioned document the rest of the job uses. There is no second copy to keep in sync.
Is this the same as ClickWerxs Command Center?
No. Command Center is the CRM and marketing platform. My ClickWerxs is the field and project operations platform, which is where drawing review lives. They are sold separately.
If your last three change orders trace back to somebody approving the wrong sheet, that is a records problem before it is a communication problem, and it is fixable. A demo walks the actual review loop on a configured tenant: a real revision, a real client markup carried forward, a real approval with its evidence stamp.
See My ClickWerxs or get in touch.
Sources
- Bluebeam, "Construction Drawing & Document Management Software" — stated audience of architects, engineers, contractors and owners; batch slip sheeting, revision tracking, role-based permissions. bluebeam.com (retrieved 2026-07-27)
ClickWerxs provides CRM software through the ClickWerxs Command Center platform. We earn revenue from businesses that subscribe. This post reflects our direct experience onboarding clients onto our platform and is not independent third-party research. Pricing and features cited are current as of publication — see clickwerxs.com/crm/features for current details.
Competitor information cited in this post is based on publicly available sources as of the publication date and is subject to change. ClickWerxs is not affiliated with the companies mentioned. All comparative claims are sourced, see source links. This post reflects operator opinion and is not legal, financial, or professional advice.
Kaleb Dickhaut is the founder of ClickWerxs and built ClickWerxs Command Center. He earns revenue from businesses that subscribe to the platform. This post reflects his direct operational experience, not independent third-party research.
Kaleb Dickhaut — Founder, ClickWerxs. Kaleb built ClickWerxs from the ground up, from payment processing ISO to the Command Center platform to the AI SEO methodology the blog runs on. He has onboarded hundreds of small businesses onto payment and CRM systems. linkedin.com/in/kaleb-dickhaut