Approval Workflows: How to Make Decisions Traceable

Information only — not legal advice.

An approval is useful when another person can establish what was approved, by whom, for which purpose and subject to which conditions. A message saying “looks good” leaves those questions open if its attachment has since changed.

Define the decision before designing the workflow

Start with a specific event: issuing a drawing, accepting a supplier deliverable, authorising a purchase or publishing a policy. Decide who has authority for that event and what evidence they need. A technical reviewer, budget holder and person authorised to release work may be different people.

Keep three outcomes distinct:

• Reviewed: someone examined the material and recorded findings.
• Approved for a stated purpose: an authorised person accepted a specific revision within their remit.
• Released: the approved package was made available to its intended recipients.

A review does not automatically authorise construction, expenditure or publication. Those permissions depend on the applicable contract, professional responsibilities and law as well as your internal process.

A decision record that survives the next revision

For each approval, capture the item identifier and revision, purpose, reviewer, decision-maker, date, result and supporting evidence. Record any conditions with an owner and deadline. Link the decision to the exact package reviewed; a link that always opens the latest editable file is insufficient on its own.

Use outcomes people can act on: approved, rejected, or returned for specific changes. If you allow conditional approval, define whether work may proceed and who confirms that each condition has been satisfied. “Approved with comments” is dangerous when some comments are essential and others are suggestions.

Worked example: a changed equipment schedule

In this fictional example, revision 3 of an equipment schedule has been reviewed for procurement. The reviewer identifies two missing power ratings. The commercial lead accepts the price, but the technical release remains pending.

1. The author creates revision 4 and describes the two corrections.
2. The technical reviewer checks the changed entries and their effect on connected drawings.
3. The authorised lead records approval of revision 4 for procurement.
4. The issuer sends revision 4 with its release record and identifies revision 3 as superseded.

The earlier price decision remains evidence, but the team confirms whether revision 4 changes its basis. Copying the old approval onto a new file would conceal that question.

Keep the process proportionate

For low-risk work, one accountable reviewer and a short record may be enough. Higher-risk decisions may need independent review, separation of duties or specialist authorisation. Agree escalation rules before a reviewer goes on leave. Silence should not become approval unless an applicable, deliberately adopted procedure says so.

Track time waiting for review, repeated returns and overdue conditions. A short approval cycle is not a success if the wrong revision reaches its users.

Try this on your next issue

Ask a colleague unfamiliar with the decision to find the approved revision, its intended use, unresolved conditions and release recipients. If they have to reconstruct the answer from several private inboxes, improve the record.

For the wider discipline, ISO 15489-1 covers principles for creating, capturing and managing records. The workflow above is a practical example, not a prescribed ISO approval form. Continue with document control and meeting minutes and action registers.

Important information

This article provides general information and does not constitute legal advice or replace a qualified professional's assessment of your circumstances. Laws, official guidance, standards and product features can change. Check current primary sources and the requirements applicable to your jurisdiction, contract and project before making decisions. Examples illustrate the discussion; they are not official rulings or instructions for a particular case. For legal decisions, consult a qualified lawyer; for technical or other specialist matters, consult the responsible professional.