You know which campaign version was approved when the sign-off is recorded against a named version of a named asset, with the reviewer and the time stored next to it. "Approved" as a reply in an email thread, a thumbs-up in Slack or a status column on a task names the campaign, not the version, so it stops being usable the moment somebody builds a revision.
The rule is one line long. If summer-sale-email-v5 was approved and somebody creates v6, the record still says v5 was approved, and it never quietly re-points at v6.
What is campaign version control?
Campaign version control is the practice of preserving each revision of a campaign asset so that comments, changes and approval decisions stay attached to the revision they describe.
A dated folder of files is not version control. The folder tells you what exists; version control tells you what each version was asked to change, what it answered, and whether anybody signed it off.
Campaigns make this harder than single-file review, because a campaign is a set of assets moving at different speeds. A four-asset promotion can sit at four different versions and three different states on the same afternoon:
| Asset | Version | State | Decision on record |
|---|---|---|---|
| Promotional email | v5 | Approved | Elena, client, 6 Aug: approved as sent |
| SMS | v2 | In review | None yet, sent to the client 6 Aug |
| Landing page | v7 | Changes requested | Legal, 5 Aug: exclusions wording |
| Terms page | v1 | Approved | Legal, 28 Jul: approved for the quarter |
A single campaign status of Approved flattens those four rows into one word. The row that survives a dispute is the one naming asset, version, reviewer and decision, which is the record campaign approval software exists to keep and the part most proofing tools treat as a by-product of collecting comments.
Why isn't a file name a version record?
A file name records an editing sequence, not an approval sequence.
It cannot show who reviewed the file, what feedback applied to it, or whether that exact revision received a decision. Every team recognizes the result:
summer-sale-email.html
summer-sale-email-v2.html
summer-sale-email-v3.html
summer-sale-email-FINAL.html
summer-sale-email-FINAL-2.html
summer-sale-email-client-comments.html
summer-sale-email-FINAL-approved.html
Read that list as evidence and it falls apart in one question: was FINAL-approved.html created before or after the client wrote the word "approved"? A designer fixing a typo, a copywriter tightening a sentence, or anyone saving over the file after the reply arrived produces exactly the same file name. The last file is not necessarily the approved file, and nothing in the name distinguishes the two.
The _FINAL convention is a versioning system with one slot. The second version goes on top of the first, and the object the approval referred to is gone.
What should happen when a new campaign version is created?
A new version starts a fresh review state and leaves the previous version's history intact.
Version history is additive: creating v5 does not rewrite what happened to v4.
- A version enters review.
- Reviewers comment on that version, and their comments stay attached to it.
- Requested changes are either applied or answered with a reason.
- A new version is created if the asset changed.
- The previous version stays readable, with its comments and its decision.
- The new version gets its own review or its own sign-off.
The comment made on v3 should not be relabeled as a v4 comment once v4 exists. Moving it forward looks like tidying and it deletes the causal chain, which is the part anyone reading the history later actually needs:
v3 client requested the CTA change
v4 CTA changed, client approved
That chain is also why centralizing campaign feedback only half solves the problem. Putting every comment in one place is worth doing, and it still leaves you guessing if nobody can tell which version each comment was written against.
Does a new campaign version cancel the previous approval?
A new version never erases the approval already recorded against the earlier one.
The approval belongs to the version that received it, permanently. What a new version raises is a different question: does that recorded decision still describe what is about to ship?
The answer depends on what changed and on what the reviewer was responsible for approving.
| Change made after sign-off | Does the recorded approval still describe what ships? | What the record has to show |
|---|---|---|
| Footer typo corrected | Yes, under most processes | v5 approved, v6 current, one line naming the change |
| Image swapped for another crop of the same shot | Usually yes | The same, with the change named |
| CTA label changed | Only if the approver's remit covered copy | The same, plus a decision on whether to re-review |
| Offer changed from 20% to 25% | No | A new round on v6: the approver never saw 25% |
| Exclusions or disclaimer rewritten | No, when legal was the approver | A new legal decision on v6 |
| Send date moved past the stated offer end | No | A campaign-level decision, not an asset one |
The failure mode is not "somebody edited a file after approval". Files get edited after approval on every campaign that ships on time. The failure mode is an old approval that appears, months later, to cover content the reviewer never saw.
So the working test is not "did anything change". It is: would the approver have needed to see this? Answer that once per change, record the answer, and the version history stops being a filing exercise and starts being usable evidence.
What is the difference between review history and approval history?
Review history records the discussion around a version: what was requested, what was answered, what changed.
Approval history records the decisions that authorize a specific version to move forward. The two are related and they are not interchangeable.
A review history reads like this:
Summer Sale email, v3
14:02 Elena, client Change the CTA to "Shop now".
14:26 Marc, copywriter Updated, and shortened the preheader.
14:31 Sofia, account Rebuilt as v4, back to you for review.
An approval history reads like this:
Summer Sale email
v3 6 Aug 14:02 Changes requested Elena, client
v4 6 Aug 16:40 Approved Elena, client
A campaign can carry twenty resolved comments and still be waiting on a decision. It can also carry a valid approval that no longer covers what shipped. Keeping both histories, tied to the same version numbers, is what makes a campaign approval audit trail readable rather than archaeological.
How should agencies track which version the client approved?
Agency version control has to make it obvious which version went to the client, which version the client answered, and whether anything changed afterwards.
The agency blocker is an external client who owes you a decision, and the handoff is where the record breaks.
The client writes:
Looks good from our side.
The account manager tells production the campaign is approved. Somebody then notices the landing page CTA still needs changing. Two readings of that message are now possible, and they are not the same decision:
Seven fields close that gap, and the last two are the ones agencies leave blank:
| Field on record | Example |
|---|---|
| Asset | Summer Sale promotional email |
| Version sent to the client | v5 |
| Client reviewer | Elena Ruiz, marketing manager |
| Decision | Approved |
| Time of decision | 6 Aug, 14:22 |
| Changed after the decision | Yes, v6 on 7 Aug, footer typo |
| Version that shipped | v6 |
An account manager should be able to answer "what exactly did the client approve?" from the record, without searching an inbox or asking the designer which attachment went out on Thursday. The wider version of this record, including response deadlines and what happens on silence, is covered in how agencies get client approvals that hold up.
How should in-house teams track which approver saw which version?
In-house version control has to preserve which version each approver reviewed, because legal, brand, channel owners and directors hold different decision rights over the same asset.
The in-house blocker is not one client, it is a group whose approvals cover different things.
Legal approves the promotional terms on landing page v4. Brand then requests a headline change, which produces v5. Whether legal has to look again depends entirely on whether the headline touched anything legal signed:
| Reviewer | Version reviewed | Scope of the decision | Outcome |
|---|---|---|---|
| Legal | Landing page v4 | Promotional terms and exclusions | Approved |
| Brand | Landing page v4 | Headline and imagery | Changes requested |
| Brand | Landing page v5 | Headline and imagery | Approved |
| Marketing director | Campaign at v5 | Release decision on the full set | Approved |
Collapse those four rows into one Approved status and you lose the only information that answers the question three months later: whose approval applies to what, and at which version. Deciding that up front, including which revisions send a stage back, is how you coordinate approvals from legal, brand and marketing without four people re-reviewing a typo.
Why isn't asset-level version control enough?
Asset-level version control stops working as proof of readiness once a campaign contains assets that reach approval at different times.
Every asset can hold a valid individual approval while the campaign still contains a contradiction between two of them.
An email at v5 approved, an SMS at v3 approved and a landing page at v7 with changes requested is two approvals and one blocked campaign. Approve the landing page at v8 and the arithmetic looks finished, until the offer expiry date on v8 disagrees with the date the email stated at v5.
Asset history answers one question: which version of this email was approved? Campaign-level approval answers the other: is the whole set ready to go out together, at these versions, on these dates? Both are needed, and version history is what makes the second one checkable rather than a matter of opinion.
How do you stop reviewers commenting on a superseded version?
Reviewers stop commenting on old versions when exactly one version is presented as open for comment and superseded versions stay readable but closed.
Attachments cannot do this. Three PDFs called v3, v4 and v5 sit in the same inbox, and nothing prevents a client from reopening v3 on Friday and replying to that thread.
The same problem arrives through screenshots pasted into chat, exported decks, duplicated share links and a document that two people opened at different times.
Three states make it unambiguous, and every version should be in one of them:
- Current. The version open for review right now. One per asset, no exceptions.
- Superseded. A previous version, readable for history, closed for new comments.
- Approved. The version that received a recorded decision, which stays labeled as approved even after it becomes superseded.
That third state is the one file names cannot express. A version can be both approved and superseded at the same time, and a team that cannot see both labels at once is the team that ships v6 believing it was signed off.
Is your version control actually working?
The test is whether the review and approval history can be reconstructed without relying on anybody's memory.
Pick a campaign that shipped three months ago and answer these:
- Which email version shipped?
- Who reviewed it, and when?
- What changes were requested, and on which version?
- Which version received the sign-off?
- Did anything change after that sign-off?
- Which SMS and landing page versions were approved?
- Was the full set approved after the last asset change?
If answering takes a search through Slack, a comparison of two PDFs and a question to the account manager, what the team has is files with version numbers in them. Under a minute, from one place, is version control.
Most tools in this category version files well and treat the decision as metadata hanging off the latest one. In LaunchSign, a review round is bound to the version that was sealed when the round opened, so a decision cannot transfer to a later edit; verdicts are appended and never edited or deleted; earlier versions stay readable with their comments attached; and a deliverable that has been through a round cannot be deleted at all. Clients review without an account, which keeps the external decision inside the record instead of in an inbox. Campaign assets are produced and approved here before execution moves to the platform your team already uses to build and send campaigns. LaunchSign does not send, and does not connect to your sending platform.
Brief → production → review → revisions → QA → sign-off → execution
The version history is the part of that line that has to survive after the campaign is over, because it is the only thing that can still answer what was approved once everyone involved has moved on to the next launch.
FAQ
What is campaign version control?
Campaign version control is the practice of preserving each revision of a campaign asset so review comments, changes and approval decisions stay tied to the revision they describe. It is distinct from file storage: a folder of dated files records what exists, while version control records what each version was asked to change and whether anybody signed it off.
How do you know which version a client approved?
Record the client's decision against a specific asset version rather than against the campaign or the task. The entry needs four things to be usable later: the asset, the version, the named reviewer and the decision, with the time it was submitted. An approval recorded only at campaign level cannot tell you which revision the client had in front of them.
Does editing a campaign after approval remove the approval?
No. The approval stays attached to the version that received it, and that entry should never be edited or moved. What editing changes is whether that decision still covers what ships. A corrected typo usually does not need a new decision; a changed offer, a rewritten disclaimer or a new send date does, because the approver never saw them.
Should old campaign versions be deleted?
Versions that form part of the review and approval history should stay available as records. Deleting them removes the evidence of why later versions exist. The active review should still show one current version so reviewers do not comment on superseded work, which is a labelling problem rather than a reason to delete.
What is the difference between version control and an approval audit trail?
Version control tracks how an asset changed between revisions. An approval audit trail records the decisions: who decided, on which version, when, and with what scope. Version control without a decision record tells you what changed and not who authorized it; a decision record without versions tells you somebody said yes and not to what.
