A campaign approval audit trail is an append-only record of who approved which version of which asset, when, and on what basis. Six fields are required, and a record missing any one of them will not survive a dispute:
- Approver identity. Who decided, and how that identity was established.
- Version. The exact version of the exact deliverable the decision applies to.
- Timestamp. When the decision was recorded, not when someone remembers it happening.
- Verdict. Approved, approved with changes, or changes requested.
- Scope. Which assets, and which aspects of them, the decision covers.
- Immutability. The entry cannot be edited or deleted after the fact.
The trail exists for one moment: the day something wrong reaches the inbox and someone asks how it got approved. Everything else is filing.
Why isn't an email thread an audit trail?
An email thread records a conversation, not a set of decisions, and the two come apart in three specific ways.
The approval that pointed at something nobody can find. The client replies "Approved, thanks" to a message whose attachment was welcome_email_FINAL_v2.html, or a share link that has since moved. The verdict survives; the object of the verdict does not. You can prove somebody said yes, not to what.
The "looks good" that predates two revisions. The approval lands Tuesday at 11:04. The copy changes Wednesday, the layout Thursday, and nobody reopens the question. Six weeks later the thread reads as approval of the campaign that shipped. It approved a version that no longer exists, and nothing marks the gap.
The approver who was copied and never replied. Four names on the To line, one reply, and a team that reads the other three as consent. At an agency the missing reply is the client contact who owed the decision. In-house it is legal or brand, copied on a thread they never opened, whose silence gets recorded as sign-off downstream.
Underneath all three sits a structural problem: every participant holds a different subset of the thread, so there is no single record to produce, only competing ones. Our guide to defensible client approvals covers the client-facing version of this record.
What are the six fields an audit trail must contain?
The six fields are approver identity, version, timestamp, verdict, scope and immutability.
Each answers a question a dispute will ask.
1. Approver identity
Good looks like a named person, with a role, and a stated mechanism: a logged-in account, or an email-restricted review link the approver entered their own address into.
Two levels exist and they are not equivalent. Authenticated identity means the person signed in to an account you control. Self-declared identity means they typed an email address on a link. Most client approvals run on the second, which buys speed and costs identity strength.
Bad looks like "the client approved it." Which person, with what authority.
2. The exact version
Good looks like a version identifier tied to a frozen artifact: v3 of Welcome email 1, sealed at 14:22 on 12 March, unchanged since.
Bad looks like approval given against a shared folder link, which resolves to whatever is in the folder today: the reviewer approved what they saw, the record points at what is there now. How to tie approval to the exact campaign version, and what a later revision does to a decision already recorded, is a discipline of its own.
3. Timestamp
Good looks like a time written by the system when the verdict was submitted, in a timezone you can state out loud. A time recalled afterwards from a phone call belongs in a note that says so, not in a field a compliance reviewer reads as machine-recorded.
4. The verdict
Good looks like three options, not two: approved ships as is, approved with changes ships once named minor edits are made, and changes requested needs a new version and another review.
The middle verdict is the one most systems lack. Without it a missing comma sends the campaign back to round one, so teams stop using the formal process for small things and the trail develops holes where the work sped up.
Bad looks like a thumbs-up emoji, which is what you get when the review surface does not separate review comments from sign-off as two different actions.
5. Scope
Good looks like a decision that names its own limits. Legal signed the disclaimer wording, not the offer or the send date. The client signed the four emails, not the landing page, still in copy at the time.
Bad looks like "the campaign is approved" when two assets were unfinished. Unbounded approvals get cited later by whoever finds them convenient, in both directions.
Scope is also the line between an asset approval and a campaign-level sign-off: one binds a single file, the other binds the whole set and the way the assets agree.
6. Immutability
Good looks like append-only: a change of mind creates a new entry and the previous one stays visible, so the history reads as a sequence of decisions including reversed ones. Bad looks like a status field somebody can set back to pending. Deleting is not correcting, and a record that can be quietly improved is not evidence of anything.
What breaks an audit trail?
Four common habits break a trail that otherwise looks complete.
| What breaks it | Why the record stops working | What to do instead |
|---|---|---|
| Overwriting a file in place | The approval names a filename, and that filename now resolves to different content | Every change creates a new version; nothing is replaced |
| Approving a link instead of a version | A shared link points at current state, not at the reviewed state | Approve a frozen version; use links for reference material only |
| Verbal confirmation | A decision with no artifact, recalled differently by each side | Record it in writing, attributed: approved by phone at 16:10 on behalf of the named approver |
| Silence past a deadline | Nobody decided anything, and the record says so | An SLA agreed in advance that states what happens on silence |
Two of those rows do most of the damage. Naming a file _FINAL is a versioning system with one slot: the second version goes on top of the first, deleting the thing the approval refers to. The same slot problem is what makes changes made after approval so destructive to a trail: the edit lands on the version the decision points at. And silence converts into consent only if that rule was agreed in writing, in advance, by the person it binds, so if you want it to hold, set a client approval SLA and get it countersigned before the campaign starts.
How much traceability do you actually need?
Not every campaign needs all six fields at full strength, and pretending otherwise is how process gets abandoned.
| Stakes | Example | What the trail has to carry |
|---|---|---|
| Low | Internal newsletter, employee survey invite | Verdict and date. A message in your project tool is enough |
| Standard | Client campaign, ecommerce promotion, product launch | All six fields, in one system, retrievable in under a minute |
| High | Regulated financial promotion, health claims, pharma, prize draws | All six fields, identity strength your compliance function accepts, and its retention period |
Placing yourself takes one question: if this goes wrong, who asks for the record, and what satisfies them?
At an agency it is a client asking who authorized the wrong price before deciding who pays for the resend, and a version-bound approval ends that conversation in one message. In-house it is a compliance or brand review months later, where the standard is not persuasion but production: either the record exists in a form your reviewer accepts, or you are reconstructing a decision from Slack scrollback in front of somebody whose job is to be unimpressed.
Most campaign approval software handles versions and comments well and treats the decision record as a by-product. In LaunchSign the verdicts are append-only, inserted and never edited or deleted, and every review round is bound to a version sealed when the round opened, so an approval cannot silently transfer to a later edit. A deliverable that has been through a round cannot be deleted at all. All three verdicts exist, and when a client approves by phone the PM records that decision on behalf of the named approver rather than losing it. Identity on client links is the address the reviewer enters, self-declared rather than verified, so treat that field as the weakest one in any account-free flow and the first to strengthen when the stakes are regulated.
The test: pick a campaign that shipped three months ago and ask who approved the version that went out, on what date. Under a minute is a trail. Longer is a thread.
FAQ
What is the difference between version history and an audit trail?
Version history records what changed and when; an audit trail records who decided what about which version. Version history answers what an asset looked like on 12 March. An audit trail answers who said it was fine, and whether they saw that version or the one before. A tool can have good version history and no usable approval record.
Is an email approval enough proof of client sign-off?
It can be, if the email identifies the specific version it approves and nothing changed afterwards. Those two conditions rarely hold together, which is why email approvals fail as evidence more often than approvers expect. If email is your channel, quote the version identifier in the request so the reply inherits it. Anything with contractual exposure belongs in front of your own lawyer.
Does silence count as approval past a deadline?
No, unless an agreement signed in advance says it does and names the deadline. Deemed approval is a contractual arrangement, not a default. Without it an unanswered request is an unanswered request, and the campaign is blocked, not approved.
How long should approval records be kept?
Long enough to cover the period the campaign could still be disputed, usually the client relationship plus the contract's dispute window. Regulated categories have retention requirements set by the compliance function, so ask them for the number. The common failure is not keeping records too briefly, it is keeping them somewhere that gets migrated with nobody responsible for the export.
