Version email copy during approvals: Assign each approval a named version to track changes; Record decisions separately from edits with clear ownership; Compare built email to approved version before sending
Image: Email Growth Desk

Email Copy

Part of Email campaign production workflows

Versioning email copy during approvals

Keep email approvals tied to a specific copy version, resolve comments in one place and reconcile the built message after changes.

Campaign Production Desk · · 3 min read

Give each approval a named copy version and keep the decision tied to it. If a subject line, offer condition or button changes after approval, issue a new review version and ask the relevant owner to assess it. An “approved” comment without a version does not establish which email was approved.

Establish the review copy

Choose one place where reviewers can see the current subject, preview text, body, buttons and any conditional wording. Mark the copy with a campaign name, version and review date.

Keep earlier versions available for comparison and record decisions separately from the text itself.

Avoid parallel copies named “final”, “final new” and “latest”. Bring feedback from email or chat into the review record before editing. Give one person responsibility for incorporating accepted changes and issuing the next version with a short change note.

Versioning Email Copy During Approvals

  1. Centralise the review copyKeep subject, preview text, body, buttons and conditional wording in one place
  2. Record decisions separatelyTrack changes, reasons, ownership and approval status per version
  3. Reconcile built email before sendCompare approved copy with final built version including recipient-specific conditions

Record decisions, not just edits

Review itemUseful record
Requested changeExact sentence or section and reason
DecisionAccept, decline or seek a fact check, with the decision owner
New versionWhat changed and which approval it affects
ApprovalReviewer, remit and version approved

In a hypothetical event email, changing “Bookings close Friday” to “Bookings close Thursday” changes a factual claim. The offer owner needs to confirm the deadline, and the copy reviewer needs to judge the revised wording.

A spacing adjustment may need design review without reopening the offer decision.

Comments in a sending tool may help collect feedback, but they are not automatically a release approval. Keep the approval decision in a record that identifies the version judged.

Before vs After Versioning: Avoiding Ambiguity

  1. Before Versioning
    Comments like 'fix this' without version reference; multiple untracked drafts named 'final', 'latest'
  2. After Versioning
    Named versions with clear change notes, decision records and single source of truth

Reconcile the built email

The review copy and the platform draft can diverge. Before release, compare the approved subject, preview text, body and action labels with the built version. Include conditional copy that changes for recipients.

For recipient-specific conditional copy, keep the built version aligned with the approved wording; use the separate technical-testing guidance for how to test it.

For an accepted late change, record the new version, affected approvals and checks to repeat. If a material fact cannot be confirmed before the planned send, hold or reschedule it. The completed record should identify the copy approved for release and explain how it differs from the first draft.

Pre-Release Checklist for Approved Email Versions

  • ✅ Approved version identifiedClear version tied to approval decision
  • ✅ All changes documentedEach edit linked to a decision owner and reason
  • ✅ Built version matches approved copySubject, preview text, body and CTAs verified
  • ✅ Conditional logic testedRecipient-specific content validated in test environments
  • ✅ Material facts confirmedDeadline, offer terms or legal disclosures verified by owner

More from Email Copy