Operations
Part of Marketing automation operations: four gates to review a platform
A marketing automation change record, from numbered intake to witnessed release
Build a marketing automation operating workflow in England with controlled intake, testing, approval, release, monitoring and incident handover.
A marketing automation operating workflow should move one change through intake, legal and data review, controlled build, witnessed testing, release and monitoring. Every stage needs an owner and a blocking condition. Platform access alone is not approval to send. The record also doubles as a test of the platform itself: a marketing automation tool that cannot supply the evidence each stage asks for is the wrong tool for a controlled operation, however good its journey builder looks.
What to take away
- A marketing automation change needs numbered intake, three decisions, controlled build, witnessed release and monitoring.
- Platform access alone is not approval to send, so every stage needs an owner and a blocking condition.
- Stop the change when counts, exclusions or previews differ from the signed evidence, and preserve the failed result.
- Close the change only after monitoring is stable for the observation period and the owner accepts residual issues.
- Reopen the record when data, content, supplier configuration or legal guidance changes.
Open a numbered change record
Give every request its number at intake, before any work starts, from one register owned by the marketing operations lead: a fixed prefix, the year and a running number. Other teams request a number from that register rather than reserving blocks of their own. Never reuse a number, and put it in the journey or workflow name inside the platform as well as in the record, so the two can be matched later. A rejected or withdrawn request keeps its number.
The record itself needs these fields, filled in order:
| Field | Filled at | Signed by |
|---|---|---|
| Change number, purpose, audience, channel, requested date | Intake | Journey owner |
| Systems affected and data fields used | Intake | Data owner |
| Privacy analysis and DPIA decision | Before build | Privacy reviewer |
| Version identifier and test results per branch | Build and test | Operator |
| Content approval | Build and test | Content approver |
| Release window, first cohort, alert thresholds, witness | Release | Journey owner and witness |
| Reconciliation, defects, closure decision | After release | Journey owner |
Store the record, its attachments and any failed results in one place the whole team can read, and keep them for the period your organisation's retention schedule sets for marketing records.
Record the business purpose, intended audience, channel, requested date, journey owner and systems affected. Attach the audience definition and content rather than describing them as "standard". Identify whether the request changes a purpose, data field, supplier, tracking technology or automated decision.
The ICO's direct marketing guidance provides the UK regulatory context for planning, collecting information, targeting and respecting preferences under UK GDPR and the Privacy and Electronic Communications Regulations (PECR). For email, text and similar stored messages, use the ICO's specific electronic-mail guidance. A qualified lawyer must apply the current rules to the recipient and facts.
Assign three decisions before building
The journey owner decides whether the request still serves the stated purpose. The data owner confirms field meanings, sources, freshness and exclusions. The privacy reviewer records the applicable analysis and whether a DPIA assessment is needed. The ICO says privacy safeguards should be integrated throughout processing in its data protection by design guidance.
Do not continue if nobody can explain where an entry field came from, how an objection reaches every destination or which team can stop the journey. Return the request with the missing evidence named.
Build and test a traceable version
Create a version identifier and link it to the approved request. Test with non-production or appropriately protected records. For each branch, write the input, expected decision, expected output and actual result. Include an invalid address, duplicate identity, suppressed recipient, late event, connector failure and manual pause.
Separate content approval from technical testing. The content approver checks sender, wording, destination, preference route and fallback. The operator checks audience logic, timing, caps, retries and logs. The security reviewer checks identities and privileges using the NCSC cloud security principles as a question set. Those principles do not certify the supplier or the local setup.
Release with a witness and rollback route
The release record should show the exact version, approvers, scheduled window, expected first cohort, alert thresholds and person watching the initial run. Use a small authorised cohort where the purpose and risk assessment permit it. Confirm that the pause control works before expanding.
The witness is a second person, not the operator who publishes, who watches the release live. They check that the version published matches the approved version identifier, that the first cohort count matches the expected one and that the pause control is within reach, then sign the release entry with the time. The operator and the witness both sign before the window closes; a release without the witness signature is treated as unapproved.
If counts, exclusions or message previews differ from the signed evidence, stop. Do not solve a last-minute discrepancy by editing production without a new record. Preserve the failed result and route it back to the relevant owner.
What the platform must evidence for the record
Before trusting a platform with this workflow, check during the trial that it can produce each piece of evidence the record needs, on the edition you would buy:
| Record stage | Evidence the platform must produce |
|---|---|
| Intake | A journey or workflow name that can carry the change number |
| Build | A version you can identify and compare with the approved one |
| Testing | A test send or test contact path that does not reach live recipients |
| Release | A pause or turn-off control, and a log of who published the change |
| Monitoring | Counts of entered, excluded, sent and failed records that can be exported |
Platforms such as HubSpot, Klaviyo, Dotdigital and Salesforce Marketing Cloud all offer journeys or workflows, test sends and reporting, but the depth of version history, audit logging and export differs by product and edition. Ask the vendor to show each row live rather than on a slide, and record the result against the platform in your evaluation.
Close the loop after release
At the agreed interval, reconcile entered, excluded, sent, failed and completed records. Investigate unexplained differences at record level. Log defects with severity, owner, workaround and target date. A dashboard that nobody reviews is not an operating control.
The GOV.UK reliability standard tells relevant public-service teams to minimise downtime and plan for failure. Private organisations are not certified by following it, but the recovery questions are useful. Close the change only after monitoring is stable for the stated observation period and the owner accepts any residual issue. Reopen it when data, content, supplier configuration or legal guidance changes.
Before you act
- Record business purpose, audience, channel, date, owner and systems affected.
- Assign journey owner, data owner and privacy reviewer before building.
- Create a version identifier linked to the approved request.
- Test branches including invalid address, duplicate, suppression and connector failure.
- Confirm the pause control works before expanding the cohort.
- Reconcile entered, excluded, sent, failed and completed records after release.
Common questions
What must be attached to the change record rather than described as standard?
The record should attach the audience definition and content rather than describing them as standard. It should also state the business purpose, intended audience, channel, requested date, journey owner and systems affected, and identify whether the request changes a purpose, data field, supplier, tracking technology or automated decision.
Who checks what during build and testing?
The content approver checks sender, wording, destination, preference route and fallback. The operator checks audience logic, timing, caps, retries and logs. The security reviewer checks identities and privileges using the NCSC cloud security principles as a question set, which do not certify the supplier or the local setup.
What should the release record show before the initial run?
It should show the exact version, approvers, scheduled window, expected first cohort, alert thresholds and the person watching the initial run. Use a small authorised cohort where the purpose and risk assessment permit it, and confirm the pause control works before expanding.
