Keep superseded drawings out of active site work
Understand the problem
TL;DR — what you’ll learn
- The most recently uploaded drawing is not necessarily the version authorised for construction.
- Control document identity, revision, review status and permitted use together, then map the approved set to the relevant work packages.
- Track distribution and withdrawal across mobile copies, prints and subcontractor handovers.
- When a revision changes active work, route the impact to the responsible engineer; a notification alone does not resolve it.
Revision C appears in the project folder overnight. The site team downloads it because the filename looks newer. The document controller later confirms that C is still under review and B remains the authorised construction issue. The folder contained both files, but did not communicate the decision.
Construction drawing revision control should answer “Which document may this team use for this work now?” That requires identity, status and scope as well as revision. The register, distribution process and site copies need to preserve that answer through changes.
- 01System version 7
- Revision B
- Authorised for the defined work front
- 02System version 8
- Revision C
- Under review; not a construction release
- 03System version 9
- Revision C
- Becomes current when formally authorised and issued
- 04If authority is withdrawn
- No automatic fallback
- Older files need explicit valid authority too
Illustrative M-204 record history. B remains usable during C’s review only if B’s authority is still valid for that scope.
Read the visual as text
System version 7: Revision B. Authorised for the defined work front. System version 8: Revision C. Under review; not a construction release. System version 9: Revision C. Becomes current when formally authorised and issued. If authority is withdrawn: No automatic fallback. Older files need explicit valid authority too.
Original explanatory visual: NextEdge Labs. Illustrative records, not client results.
- STEP 01Read identity and status
Owner: Document controller
Drawing number, revision, version, purpose and scope.
- STEP 02Confirm the authorised set
Owner: Discipline authority
Check release criteria, restrictions and withdrawn issues.
- STEP 03Distribute and withdraw copies
Owner: Document controller + supervisors
Target recipients; handle offline files and controlled prints.
- STEP 04Review changed work
Owner: Responsible engineer
Assess work planned, in progress and already installed.
Distribute the controlled issue and assign its impact review.
Show review-only, withdrawn or no-authorised-issue status; seek the discipline decision.
Return path: Refresh the set from the authority source before distribution resumes.
Read the workflow as text
1. Read identity and status (Document controller) → 2. Confirm the authorised set (Discipline authority) → 3. Distribute and withdraw copies (Document controller + supervisors) → 4. Review changed work (Responsible engineer). After step 2, ask: Is this issue authorised for this work and scope now? Yes: Distribute the controlled issue and assign its impact review. No: Show review-only, withdrawn or no-authorised-issue status; seek the discipline decision. Return: Refresh the set from the authority source before distribution resumes.
Workflow: NextEdge Labs. Apply the project’s actual authority and procedures.
Separate revision from permission to use
Illustrative example: drawing M-204 covers a plant-room pipe arrangement. The project uses the following hypothetical statuses; actual wording and authority should follow its approved document-control procedure.
| Record | System version | Design revision | Status | Use at the work front |
|---|---|---|---|---|
| Earlier issue | 7 | B | Authorised for construction | Current authorised reference |
| New upload | 8 | C | Under review | Review only |
| Later accepted issue | 9 | C | Authorised for construction | Replaces B when formally issued for the applicable scope |
The highest system version is not a sufficient selection rule. Revision C may have several uploaded versions while comments are addressed. Conversely, a metadata correction may create a new system version without a design change.
The example assumes B's authorisation remains valid while C is reviewed. If B is withdrawn, the system must show that there is no currently authorised issue for the affected scope until the responsible authority resolves it. It must not fall back to an older drawing merely to keep the work-front list populated.
Oracle’s Aconex document reference distinguishes revision, system version and review/document status. A project integration should preserve those distinctions rather than collapse them into a single “latest” flag.
Build the authorised set around the work
Maintain a stable document number, title, discipline, package or location, revision, status, responsible originator and relevant issue/transmittal reference. Add the permitted purpose of use according to the project procedure. A drawing for review should not appear in the same operational view as one released for construction without a clear status distinction.
Map the document to the work fronts that need it. A site-wide email about every new drawing makes it difficult for a supervisor to identify the one that changes tomorrow’s work. The distribution list should follow discipline, package and responsibility, with a way to handle staff and subcontractor changes.
Aconex’s High Compliance Environment guidance illustrates filtering a current drawing set by document type and status. Verify the available controls in the installed environment and check its criteria against the project's use rules. A default drawing tab is not independent evidence that every displayed document is appropriate for every activity.
Treat distribution as a handover
When an authorised revision is issued, record who needs it, what it replaces and what acknowledgement is required. Provide a link to the controlled source where practical, while recognising that work fronts may need approved offline or printed copies.
For controlled prints, use an identifiable copy record and a withdrawal or replacement process. The supervisor should be able to check the drawing number and revision against the authorised register. A loose print without status or issue information is difficult to manage after it leaves the office.
For mobile copies, show the last successful synchronisation and whether an update is pending. A device that has been offline since yesterday cannot confidently report that it holds today’s authorised set. Define how the team verifies the current issue before relying on a stale copy, using the approved site procedure.
An acknowledgement confirms receipt or review under the defined workflow. It does not prove that every old print has been removed or that the work has been checked for impact. Use it as one control in the handover.
Give changed work an engineering owner
When revision C becomes authorised, the engineer should assess what changes for work not started, work in progress and work already installed. Document control can identify the affected drawings and recipients, but it should not decide whether completed work is acceptable or requires modification.
Record the affected package, location, instruction or review reference, responsible engineer and status of the impact assessment. If commercial consequences arise, route them through the authorised contracts process. Do not let a drawing upload silently create an approved variation or contractual notice.
Where a revision is withdrawn or its status changes, treat the event with the same seriousness as a new issue. A system that only notifies users of new files may miss the more important fact that a previously authorised document is no longer available for the intended use.
A partial release needs equally clear boundaries. If an issue is authorised for one zone while another remains under review, record that scope explicitly and obtain the discipline lead's instructions. A project-wide “approved” badge can conceal the restriction even when the underlying transmittal is correct.
Test the difficult retrieval cases
Ask a supervisor to locate the authorised drawing for one work front. Then introduce a newer unapproved upload, a similarly named drawing from another package and a withdrawn issue. The correct reference should remain unambiguous.
Next, disconnect a device, release a revision and reconnect it. Check how the update appears, whether the old copy remains accessible for historical purposes and how it is prevented from being mistaken for the active issue. Historical records are valuable, but their status must be visible.
Finally, revoke a subcontractor user’s access. Verify the project’s defined treatment of downloaded content and future links. Do not assume removing a name from a notification list removes access everywhere.
Choose the smallest workable control system
A controlled register and disciplined transmittal process may be sufficient for a small project with few documents and recipients. A DMS becomes more valuable as revisions, organisations and review workflows multiply. An integration can help distribute alerts and show acknowledgement gaps when the DMS already owns the approvals.
Measure time to retrieve the correct authorised issue, unacknowledged critical distributions and the age of unresolved revision-impact reviews. Test retrieval at the work front, not only in the document controller’s account.
If users routinely work from personal message attachments, investigate why: access may be slow, filenames unclear or the official view difficult to search. Fixing that friction can matter as much as adding another approval field.
Make the work-front answer unambiguous
Revision control succeeds when the person doing the work can identify the applicable authorised document and the organisation can explain how changes reached that person.
- Agree document identity, status and permitted-use definitions.
- Build a package-specific view of the authorised drawing set.
- Test distribution, offline copies and withdrawal of superseded prints.
- Assign engineering review for changes affecting active or completed work.
- Use a document-control integration pilot if notification and acknowledgement gaps remain.
Recognise this problem in your operation?
Tell us where the records or handovers break down. We can discuss the process, data and software questions worth examining first.
References and further reading
Sources checked 15 October 2026. The worked examples and diagrams are original editorial explanations, not client results.
- Oracle Aconex — Documents subject-area referenceDocument status, review status, revision and system-version attributes
Product metadata distinctions.
- Oracle Aconex — Define the current set of drawingsDefault drawing-set criteria and configurable filters
High Compliance Environment configuration example.
Visual credits
Original explanatory visuals and workflow diagrams by NextEdge Labs. Labels and text equivalents are included in the page. Numerical scenarios are illustrative; diagrams preserve the project owner’s approval and exception decisions.