DATIMORE · WEB-032

Know which document version the team may use

Approval matrix and worked example. Save or print this page to plan one document approval process. Replace the invented policy with rules agreed by your company.

Synthetic planning aid. The people, authority rules and deadlines below are invented. The rules were checked in a small test program; this is not a deployed workflow or evidence of client results.

1. Agree who can decide

Example owner: operations manager. The author cannot approve their own document. If two roles must approve, they must be held by different people. Unknown document types, missing versions or missing authority mean HOLD until the owner resolves the gap.

2. Agree the rules behind the status

1. Record the request reference, document version, author, document type, named approvers, decision, reason and time. Give each required step a deadline. In this example each step has a 24-hour deadline; this is an invented elapsed-time rule, not a working-day calendar.
2. The owner authorizes a deputy in advance for a named role, document type and start/end time. Check that authority when the deputy responds. After reassignment, the former assignee cannot decide on that step. A reminder or copied email never grants authority.
3. A rejection closes that review with a reason and no permission to use the document. To correct it, submit a new version for a new review. Under this example policy, any new version resets all required approvals. Keep the old decisions in the history.
4. At or after a deadline, mark the step overdue and alert the process owner. Do not approve or release it. The owner must explicitly reassign or reopen the step with authorized people and a new deadline; this recovery is outside the small model tested below.
5. Immediately before recording permission to use a version, check that it is still current and all required decisions are valid. Create only one release record for that request and version. A repeated event must reuse that record. A changed version requires a new review.
6. Actual customer sending is outside this model. The sender checks the approved file and recipient access. If sending is uncertain, check the delivery record before trying again. An approval record alone cannot confirm delivery.

3. One request, three possible outcomes

Request DOC-32: customer notice changing a delivery date, version 2. A coordinator writes it. The service lead approves at 09:00 UTC on 5 October 2026; the operations step is then due at 09:00 UTC on 6 October. The authorized operations deputy has authority for this document type from 5 October 00:00 to 7 October 00:00 UTC (end excluded). Each case below starts afresh from that same approved first step.

Other checks and limits

The local model also rejected an unknown document type, a missing version, self-approval, an unassigned approver, an expired delegation, a decision from the former assignee and a decision for an old version. Changing version 2 to version 3 cleared the active approvals and kept the old decision history. Version 3 remained unavailable for use until a new review. These tests check the invented rules only. They do not test a live platform, permissions, notifications, outages or simultaneous updates.

Adapt it to your team

Background: Microsoft documents scoped and time-bounded delegation. Google Drive explains its configurable approval behavior. Product settings differ. The rules above are this example’s policy, not a claim that every product enforces them automatically.

Read the approval-workflow article