Keeping an audit trail of campaign sign-off

A campaign sign-off trail should answer four questions later: which version was reviewed, who decided, what they decided and what actually went out. A notification thread alone rarely answers all four, especially if the draft or audience changed after someone replied.

Record a decision, not just a status

Give each campaign a stable ID and each material draft a version. Use the same identifiers in the approval event and publication record so they can be matched later.

Keep the reviewable creative and audience definition, or a durable reference to their snapshots. Record superseded, cancelled and timed-out requests too; otherwise a later reader may mistake an old approval for a current one.

Microsoft's standard approvals connector uses the AssignedTo field for approval recipients and accepts case-sensitive “Approve” and “Reject” responses for Basic or Await all approvals. Preserve the response exactly as recorded, including its case.

Approval details show the flow creator to prevent spoofing of approval sender identities. Keep that system detail distinct from the assigned recipient and recorded decision-maker.

Link each approval event to the specific campaign version in your own workflow. Microsoft notes that approvals timestamps are shown in UTC, so show a consistent time zone when people reconstruct a launch.

Connect approval to publication

At release, record the exact campaign version, final audience or segment version, schedule and the person or automation that initiated the send. Store the final creative snapshot where the team can retrieve it.

If the system exports a send ID, associate it with the campaign ID. A reviewer can then compare the approved state with the published state rather than inferring a match from similar names.

Decide which changes require renewed sign-off. A changed product claim or recipient segment should normally invalidate the affected decision. Write the exception rule for minor corrections so the trail remains honest: it should show what changed, who accepted the change and why a full reroute was unnecessary.

Make the record usable

Test a retrieval task: choose an old campaign and ask someone outside the launch team to find the final copy, audience scope, required decisions and send record. If they cannot, improve the fields or storage.

Set retention and access based on your organisation's needs and applicable rules; do not assume an automation service's run history is permanent. A durable record may require a designed store rather than reliance on the workflow screen.

For an APP entity's sign-off records containing personal information, the OAIC's APP 11 guidance requires reasonable steps to protect it from misuse, interference, loss, and unauthorised access, modification or disclosure. Restrict access to support that protection.

APP 11.2 sets no fixed number of years: an APP entity must take reasonable steps to destroy or de-identify personal information once it is no longer needed for a purpose allowed under the APPs. The exception is where the information is part of a Commonwealth record or an Australian law or court or tribunal order requires retention.

Set a documented review and disposal trigger for this record category, and check for any applicable retention requirement before destruction or de-identification. Keep enough context to explain a complaint, correct a mistake and improve the next launch, without collecting unrelated personal data simply because the tool permits it.