Keep the original sign-off attached to the version that received it, then test whether the change touches what that reviewer was responsible for approving. If it does, reopen that stage on the new version. If it does not, carry the decision forward and say so in the record, visibly, rather than letting it renumber itself onto a version nobody reviewed.
The version number moving is not the question. A corrected footer typo and a discount going from 20% to 25% both produce v6, and only one of them makes the previous approval stop describing what ships.
What does approval actually apply to?
A sign-off is a decision by a named reviewer, covering a defined scope, on one specific version, at a point in time.
Take any of those four away and the record stops being usable. This is the difference between two entries that look equivalent in a project tool:
Campaign approved
Email v7 approved by the client, 6 Aug 14:22, offer and creative as sent
The first names a campaign, which is not a thing anybody reviewed. Nobody read "the campaign". They read an email at a particular revision, on a particular afternoon, and formed an opinion about the parts of it they are responsible for.
The consequence for editing is direct: approval history must not move when a new version appears. If v5 was approved and v6 exists, the record still says v5 was approved, and v6 carries whatever decision v6 has actually received, including none. Most campaign approval software versions files competently and then attaches the approval to the deliverable rather than to the revision, which is the exact mechanism by which an old decision ends up appearing to cover new content. The underlying discipline is tracking approved campaign versions, and everything below assumes it.
Does every change require re-approval?
No, and a process that says otherwise gets abandoned within about two campaigns.
The useful question is not whether the asset changed. It is whether the change lands inside the scope of an approval somebody has already given.
| Change made after approval | Approval potentially affected | Why |
|---|---|---|
| Hero image swapped for a different shot | Brand | The creative the reviewer approved is no longer the creative that ships |
| Offer moves from 20% to 25% | Legal or the commercial approver | The promotional claim changed |
| CTA changes from "Learn more" to "Shop now" | Brand, or the campaign owner | Approved copy changed |
| Footer typo corrected | Depends on your approval policy | The version changed, the decision scope may not have |
| Landing page expiry date moves to Monday | Legal, and the campaign owner | The promotional terms changed |
| Tracking parameter added to a link | Production or QA | The destination and the execution detail need re-checking |
Read that middle column as "potentially". None of it is a rule that holds across organizations, and it is not legal advice. Whether a corrected typo needs another pass is a policy question your team answers once, in advance, and writes down. What does not vary is that the question gets asked, against a named scope, rather than resolved by whoever is in the room.
How do you decide which approvals to reopen?
Compare the change against each approval scope, one at a time, and reopen only the ones it lands in.
Seven steps, in order:
- Name exactly what changed, in the words a reviewer would use, not "updated the email".
- Identify the asset and the version the change produced.
- Compare the change against each existing approval scope on that asset.
- Reopen the stages the change lands inside.
- Leave the other decisions standing, visibly attached to the version they were given on.
- Record the new decision against the revised version.
- Re-confirm campaign-level sign-off if the change affects whether the set still holds together.
Step five is where most workflows fail, in both directions. Deleting the untouched approvals and asking for them again is how a two-hour fix becomes a three-day round. Silently promoting them onto the new version is how a campaign ships with an approval record that describes a version nobody has seen. Neither of those is a version of "we checked".
What happens to the original approval?
The original approval stays on the version that received it, unchanged, forever.
It is not deleted when a new version appears and it is not transferred to it.
Email v5 client approved, 6 Aug 14:22
Email v6 CTA changed after the client's request
v5 still shows as approved, historically, by that client, on that date
v6 is the current version
v6 holds whatever decision the workflow requires, which may be none yet
Two things make this worth the discipline. The first is auditability: an append-only history can be read months later by somebody who was not there, and a mutable status field cannot, because there is no way to tell whether it was ever set to something else. The second is narrower and comes up more often. When a campaign goes out wrong, the question is never "was it approved". It is "which version was approved, and was that the version that shipped", and only a preserved history answers it.
What happens if legal-approved content changes?
A legal approval covers the content legal actually read, at the version they read it on.
It does not extend forward to wording they never saw, regardless of how small the edit looks from the marketing side.
Landing page v4
Offer: 20% off selected products
Legal: approved, promotional terms
Landing page v5
Offer: 25% off all products
The v4 decision remains valid, and it remains a decision about v4. It is not evidence that legal reviewed the claim in v5, because two things moved that sit squarely inside legal's scope: the number and the word "all". Whether v5 needs another legal pass is your organization's call, made by your compliance function rather than by a blog post, but the record should not present v4's approval as though it answered the question.
Legal approval is also not interchangeable with the other two decisions on the same asset. Brand approving the creative says nothing about the terms. The marketing director's final sign-off is a release decision, not a substitute for either. Keeping the three distinguishable is the substance of a role-specific approval workflow, and it is what makes the reopening question answerable at all.
How should in-house teams handle changes after approval?
Evaluate the change against the decision rights of each approver, because in-house the blocker is a group of roles with different scopes rather than one person with a queue.
A normal week produces this:
Email v5 Legal approved the terms
Brand approved the creative
Email v6 Marketing rewrites the headline
Email v7 The CRM owner fixes a rendering problem in the footer
The headline rewrite and the footer fix are not the same event. The headline may sit inside brand's scope, and inside legal's too if it restates the offer. The rendering fix probably sits inside production readiness and nowhere else. Two versions, two different sets of reopened stages, and no reason for the second one to disturb legal.
The failure to avoid is the one where nobody owns the question. The headline gets rewritten on Thursday afternoon, everyone assumes the earlier approvals still stand because the campaign status still reads approved, and the version that goes out has a claim in it that legal has never read.
What happens if a client requests a change after sign-off?
Treat a post-sign-off client request as a new revision, never as an edit to the version the client already approved.
At an agency the blocker is an external client who owes you a decision, and the record of that decision is the thing you will be asked to produce.
The client approves Summer Sale Email v6 at 14:22. At 16:40 they email:
Can we make the CTA "Shop the sale" instead?
What that must not produce is a corrected v6. What it should produce is:
v6 client approved, 6 Aug 14:22
v7 CTA changed to "Shop the sale" at the client's request, 6 Aug 16:40
Then the workflow decides whether v7 needs another client sign-off. Often it does not, because the client requested the change themselves and the request is in writing next to the version. That written request is doing real work: it is the reason v7 can proceed without a second round, and it belongs in the record for exactly that reason.
The case to watch is the request that arrives in a phone call, or the small "while you're in there" addition that gets folded in alongside it. Both leave you with a shipped version whose only approval belongs to a different one, which is the position campaign approval software for agencies exists to keep you out of.
What happens when one asset changes after campaign-level approval?
A campaign-level sign-off describes the set as it stood when it was signed, so a later change to one asset puts that decision back in question even when the asset's own approvals are handled correctly.
Start from a fully approved campaign:
Email v7 approved
SMS v3 approved
Landing page v6 approved
Campaign signed off
Then: landing page moves to v7
Two checks follow, not one. The first is the asset check: which landing page approvals does the v7 change reopen? The second is the one teams skip, because the assets each look fine on their own:
Email v7 Offer ends Sunday
Landing page v7 Offer ends Monday
Both assets are internally correct. Both carry valid approvals. The campaign contradicts itself, and no asset-level reviewer was in a position to catch it, because neither of them had the other document on screen. That is precisely the layer campaign-level approval exists to cover, and a change to any asset after that sign-off is the most common way the layer gets quietly invalidated.
How do you document a change after approval?
A post-approval change record has to let somebody reconstruct the sequence without asking anyone who was involved.
Ten fields do it:
- Previously approved version
- Reviewer who approved it
- Their approval scope
- Their decision
- New version
- What changed, specifically
- Who requested or made the change
- Which stages reopened
- The new decision
- Resulting campaign status
Fields six and eight are the ones that turn a version log into an approval record. "Updated the email" in field six is worthless six weeks later; "CTA changed from Learn more to Shop now" can be compared against a scope. An empty field eight is not neutral either: it should read "none, brand scope not affected" rather than nothing at all, because a blank is indistinguishable from nobody having asked.
Those entries are not a separate document. They are events in the campaign approval audit trail, which is only as good as its treatment of the moments when something changed after a decision was made.
How do you avoid restarting every approval from scratch?
Scope the re-approval to the change, and the process stays usable.
The objection is fair and worth stating plainly: if every edit sends the campaign back to four stakeholders, people will stop making edits through the process, and you will have traded a slow workflow for an invisible one.
The middle ground has four positions, and two of them are wrong:
In practice, most post-approval changes touch one scope or none. A typo, a tracking parameter, a compressed image: these should cost one line in the record and nobody's afternoon. A claim, a price, a date, a disclaimer: these should cost exactly one reopened stage, the one that owns them.
The teams that get this right tend to find the total number of rounds falls rather than rises, because the rounds that do happen are aimed at somebody with a reason to be looking. The same principle applies upstream, where most of the waste actually lives: see reduce campaign review rounds for the earlier half of that problem.
Where does LaunchSign fit after a campaign changes?
LaunchSign is campaign production and client approval software, covering the work from brief through production, review, QA and sign-off.
The part that matters after a change is that a review round is bound to the version that was sealed when the round opened, so a decision cannot slide onto a later edit, and verdicts are appended rather than edited or deleted, so a reopened stage adds an entry instead of overwriting one. Earlier versions stay readable with their comments attached, and a deliverable that has been through a round cannot be deleted at all.
Each asset type carries its own pipeline of phases with a named owner on each, which is what lets you reopen one stage rather than the whole sequence, and clients review without creating an account, which keeps the external decision inside the record instead of in an inbox where the next revision cannot reach it.
Campaigns are produced and approved there before execution moves to the platform your team already uses to build and send campaigns, such as Salesforce Marketing Cloud, Braze, Klaviyo or HubSpot. LaunchSign does not send, and does not connect to your sending platform.
What no tool decides for you is the policy: which changes reopen which scope. That is an organizational decision, and it is worth making before the campaign that needs it.
FAQ
Does every campaign edit require re-approval?
No. Test the edit against the scope of each existing approval rather than against the version number. A tracking parameter or a corrected typo usually lands in nobody's approval scope, while a changed offer, claim, date or disclaimer lands in somebody's. Which of the borderline cases need another pass is a policy your team sets in advance, not something to decide per campaign under deadline.
Does a new version invalidate the old approval?
No. The old approval stays permanently attached to the version it was given on, and stays valid as a statement about that version. What a new version can do is make that approval stop describing what ships. Those are different things, and conflating them is what produces records that appear to authorize content nobody reviewed.
What happens if legal-approved copy changes?
The legal decision remains a decision about the version legal read. It is not evidence that legal reviewed the new wording, so the change has to be assessed against what legal was responsible for: claims, promotional terms and disclaimers. Whether the revised version needs another legal pass is for your compliance function to decide, but the record should never present the earlier approval as covering it.
Can a client request changes after signing off?
Yes, and it is routine. Handle it as a new version rather than an edit to the approved one, and keep the written request next to it. That request is often what allows the revision to proceed without a second sign-off, because the client asked for the change themselves. Verbal requests are the risk: without something written, the shipped version has no decision attached to it at all.
Should campaign-level approval be repeated after an asset changes?
Repeat it when the change affects whether the assets still agree with each other, which is what the campaign-level decision asserts. A new image on one email usually does not. A changed date, offer, or link destination usually does, because those are the fields that have to match across channels. The asset can be individually approved and the campaign still be wrong.
