How to keep email approvals linked to the right document version

A supplier proposal is approved by email on Tuesday. On Wednesday, someone updates the pricing in the same document. By Friday, the team has an approval message and a revised proposal, but no clear record showing whether the new figures were authorised.

The email has not disappeared. Neither has the document. What is missing is a reliable connection between the decision and the version reviewed.

An approval record should identify the exact document version, the person who approved it, the date and any conditions attached to the decision. Without those details, “approved” can become open to interpretation as soon as the file changes.

Here is how to keep that connection clear throughout the document’s life.

1. Identify the version before requesting approval

A filename such as Supplier_Proposal_Final.docx tells the reviewer very little. It may have been edited several times without being renamed, and another “final” copy may already exist elsewhere.

Keep the working document in a controlled location and use its recorded version number when requesting approval. In SharePoint, version history allows users to review earlier versions and, for supported Office documents, compare changes between them. This provides a stronger reference than a filename alone.

Each approval request should include:

• The document title and a unique document or project reference.
• The exact version submitted for review.
• A link to the review copy, with suitable access permissions.
• The decision required, including its scope.

For example, “Please approve the attached proposal” could become:

“Please approve Supplier Proposal SUP-024, version 3.0, for issue to the client. This review covers the pricing and delivery terms.”

The reviewer now knows what they are being asked to authorise.

2. Make sure the review copy cannot change unnoticed

Sharing a link reduces the number of attachments circulating through inboxes. However, a normal link to a working document does not, by itself, establish which version someone reviewed.

If the file changes while approval is pending, the requester and approver could be looking at different content through the same link.

Use a process that fixes the review version. Depending on your systems, this could mean a version-specific reference, a protected review copy or an approval workflow that detects changes and requires a fresh request. Confirm that reviewers can access the intended version before sending it.

Microsoft’s modern approvals in Lists and document libraries illustrate this safeguard: saving changes to a file cancels an approval that is in progress. Microsoft also warns that updates to the item’s metadata can reset approval status. That behaviour is specific to this approval feature; it should not be assumed for every email-based or custom workflow.

Where external reviewers require attachments, preserve the exact attachment sent for approval and associate it with the controlled document record. Their response should refer to that copy explicitly.

3. Ask for a decision that states its scope

“Looks fine” may mean the layout is acceptable. “Happy to proceed” may refer only to the budget. Neither necessarily confirms approval of the complete document.

Make the required response clear in the request. For example:

“Approved: Supplier Proposal SUP-024, version 3.0, for issue to the client, including the pricing and delivery terms.”

Conditions need equal attention. “Approved subject to correcting the payment terms” should not become an unconditional approval in the document register.

Record the condition, assign responsibility for the change and establish whether the corrected version requires another review. Where several people approve different elements, preserve those distinctions. Finance approval of the price does not automatically establish approval of the technical specification.

4. Record the relationship between the email and the version

Saving an approval email in the same project folder as the document helps people find it. It does not necessarily show which revision the message concerns.

Use an approval register, linked records or configured metadata to make the relationship explicit. A practical record could contain:

These are recommended fields for the process; they are not automatically captured by every filing tool.

Preserve the original approval message, including its sender, recipients, timestamp and relevant attachments. Retain earlier correspondence where it explains the scope or conditions. A screenshot or a manually entered “Approved” label provides less context than the underlying message.

For teams working in Outlook, Konnect eMail’s SharePoint email management tools can help save emails and attachments into SharePoint and capture email metadata. The document reference and approved version still need to be recorded through the organisation’s configured fields or approval process. Saving the email is one part of maintaining the connection.

5. Treat later revisions as a new approval question

Approval of version 3.0 should not silently extend to version 3.1.

Define which changes require renewed approval. Revised prices, contractual terms, technical requirements or delivery commitments should trigger a review by the relevant decision-maker. Minor formatting corrections may follow a lighter process, provided that exception is documented.

Keep the earlier approval associated with the earlier version. If a new revision needs approval, record it as awaiting review rather than allowing the previous decision to imply authorisation.

When automating approvals, ask a specific question: what happens if the document changes after the request is sent?

Microsoft’s SharePoint and Power Automate guidance uses an ETag, an identifier for the specific item version pending approval, when setting content approval status. This highlights why a workflow needs version information alongside the document’s identity. Test the change scenario before relying on the workflow in daily use.

6. Keep the evidence retrievable for as long as it is needed

An approval trail remains useful only while the reviewed version and its supporting evidence can be retrieved.

Check that your retention arrangements cover both. SharePoint version-history limits can remove older versions as new ones accumulate, so retaining an approval email does not necessarily mean the approved document version will remain available indefinitely.

Give the document owner responsibility for checking the completed record. Someone who did not participate in the email exchange should be able to establish what was reviewed, who approved it, what conditions applied and whether the document changed afterwards.

Make the decision clear beyond the inbox

Reliable email approval depends on a small set of consistent habits: identify the version, preserve the review copy, state the decision clearly and retain the evidence with an explicit reference to that version.

When those habits are built into the process, teams can act on approvals confidently, and explain those decisions later without reconstructing an email conversation from memory.

Frequently asked questions

Is an email saying “approved” enough?

It may communicate a decision, but a useful business record also needs to establish what was approved. Identify the document version, scope, approver and any conditions. If the message is ambiguous, clarify it before treating the document as authorised.

Does sending a SharePoint link keep approval tied to a version?

A normal link to a working document is insufficient on its own. Record the reviewed version and use a process that preserves it or detects subsequent changes. Check how your chosen approval feature handles edits while a request is pending.

Should every document change require another approval?

Set rules according to the significance of the change. Changes to commercial terms, obligations or specifications should receive the relevant review. Minor corrections may follow a documented exception, but the record should still show what changed after approval.