?Approved? is a surprisingly incomplete label. Approved by whom? Which revision did they read? Does the decision permit work to start, or does it only accept the proposal for further review?
An approval workflow should make those answers recoverable. We design the decision around a specific version, with enough context for the reviewer to understand the change and for someone else to understand the decision later.
Our drawing and report review project makes this problem concrete. A drawing can be current, received and still awaiting a decision. Those states deserve separate records.
A small drawing change can create a new review
In the project, drawing A?102 moves from revision B to revision C. The entry door changes from the south wall to the east wall. The reception desk stays in place, the number of meeting rooms stays the same and the workroom access is unchanged.
That is more informative than saying ?floor plan updated.? The new entry affects the arrival sequence and the view towards reception. The reviewer needs to consider those consequences without rechecking every unchanged room.
We show the two plans together, followed by a comparison of the changed and retained elements. Revision B remains identifiable as superseded. Revision C is the current review copy, not a construction issue.
Show the change that needs a new decision
The comparison also states that approval is not inherited from revision B. This is the point a generic activity feed can obscure: a previous decision remains true about the earlier object, but it does not automatically authorise its replacement.
Keep delivery and acceptance separate
The transmittal register records which drawings were included in a shared set and when receipt was recorded. Its job is to establish what was issued. The review history has a different job: explaining comments and decisions.
Combining those into one ?complete? status creates an avoidable ambiguity. A coordinator may have delivered the right files while the reviewer still has an unresolved question. Both facts should be visible.
| Event | What it establishes | What it does not establish |
|---|---|---|
| New revision issued | A replacement version is available | Earlier approval applies |
| Receipt recorded | The issued set reached the recipient | The contents were accepted |
| Comment resolved | A particular concern was addressed | Every required decision is complete |
| Approval recorded | An authorised decision concerns a named version | Future revisions are covered |
Show the consequence of a change beside the change
The same reasoning applies outside drawing review. In our landscape material approval project, revision 03 replaces porcelain with limestone while retaining the terrace, path and planting quantities.
The sample inclusive total moves from AUD 18,400 to AUD 20,000. Showing the AUD 1,600 difference alongside the material choice lets the reviewer connect appearance, retained scope and cost. A photograph of limestone alone would leave two-thirds of that decision elsewhere.
These are sample proposal figures from the project. Their value in this discussion is the structure of the comparison: what changes, what remains and what follows if it is accepted.
Version and decision
- 01PrepareIdentify the proposed version and its changes.
- 02ReviewShow scope and consequences to the authorised person.
- 03RecordKeep the decision attached to that exact version.
Make the current decision easy to find without erasing the earlier one
History should help a person answer a question, not force them to reconstruct the entire project. Put the current version and its decision at the point of use. Keep earlier versions accessible with clear dates and dispositions.
An old email link should still lead to an intelligible record. If the linked proposal is no longer current, explain that and offer the current version. Quietly replacing the attachment behind the link risks making an earlier message appear to refer to something its sender never reviewed.
Our quotation and order-release workspace applies the same principle to a controlled specification and its commercial record.
Agree what approval permits
Before building the approval button, ask the team to finish the sentence ?After this decision, we may?? It could mean issuing a document, ordering materials or moving to another review stage. If different people give different answers, the workflow is not yet defined.
Production permissions must enforce that authority when the decision is submitted. OWASP's authorization guidance covers the implementation principle; the interface should make the scope of the decision equally clear to the reviewer.
A received drawing set can still await approval
Our workflow management guide covers ownership across the wider process. When we build client portals, we carry that ownership down to the individual proposal and version. If documents must be collected first, the collection workflow should distinguish a complete pack from an approved one.
Sources and calculation notes
The landscape project records revision 03 and sample inclusive totals of AUD 18,400 and AUD 20,000. Difference: 20,000 - 18,400 = AUD 1,600. These are authored project amounts, not a real invoice or measured outcome.
- Our drawing and report review project. The project page includes the design account, delivered scope and screenshots discussed in this article.
- Our landscape proposal and material approval project. The project page includes the design account, delivered scope and screenshots discussed in this article.
- Our quote revision and order release project. The project page includes the design account, delivered scope and screenshots discussed in this article.
- OWASP authorization guidance. Supports checking production permissions on requests; it does not validate the portfolio implementation.
External references checked on 31 October 2026.