Approval-gate checklist for reviewing a campaign automation platform

What to take away

What COBS 4 requires before a scheduled campaign goes out

COBS 4 sets the financial promotion rules for FCA-regulated firms. COBS 4.2.1R requires a promotion to be fair, clear and not misleading before it reaches a client. The detailed rule text is in the FCA Handbook, COBS 4, Communicating with clients, including financial promotions.

A scheduled campaign is still a promotion. The fact that a system sends it at 07:00 on a Tuesday does not change the approval duty. The person who signs off must be competent to do so and must have seen the final copy, including personalisation logic.

Sign-off accountability sits within the FCA's Senior Managers and Certification Regime (SM&CR), which replaced the approved persons regime for most firms. Approving a financial promotion is not automatically a certification function, so the firm must check its allocation of responsibilities before naming an approver.

COBS 4 also covers the medium. Email, SMS, push notification and in-app message all count. If your automation platform can send it, COBS 4 applies to it.

The rule looks at the overall impression, not just the individual sentences. A balanced promotion gives the risks the same prominence as the benefits. Automated templates make it easy to lose that balance, because the benefit line is the one the team tests most.

Risk warnings need to be legible and near the claim they qualify. A footnote that only appears in the desktop rendering will not pass review. Marketing teams should check every version the platform can produce.

Firms must also consider who the promotion reaches. A campaign aimed at retail clients carries a different standard from one aimed at professional clients. The audience definition in the workflow should record which category applies.

Reviewing approval steps in an automated workflow

An approval step is a gate, not a comment. The workflow should stop until a named person approves the exact version that will send. Use four gates between build and send as a model: intake, build, approval, release.

This mirrors numbered intake to witnessed release, where each stage leaves a trace. The platform should not allow a schedule to be set before the approval gate is passed.

Test the gate as a hard stop, not as a status field a human has to check. In a test campaign, try to schedule or release without approval; confirm the send is blocked and that the outcome is recorded.

Set and test a deadline for approval requests. Check whether an unanswered request can be escalated, and ensure it cannot silently expire into a live send.

Rejections matter as much as approvals. A rejected draft should return to the builder with the reviewer's reason attached. That reason becomes part of the record if the copy is later revised.

For firms running automation as a service, the approval gate belongs in the service definition, not in a side email. The client signs off, the provider stores the record. The four gates between build and send should be written into the contract.

If the campaign includes consent-based audiences, the consent records sit alongside financial promotion approval. UK GDPR and PECR set the consent rules, and the ICO guidance on consent explains what a valid consent record contains.

Consent and approval are separate tests. A client may have consented to marketing and the copy may still breach COBS 4. Both records need to exist, and neither substitutes for the other.

Reviewing platform approval gates

This article publishes no test results for the platforms below. Each one is a candidate to run through the checklist later in this article, in the firm's own edition and configuration.

For HubSpot Marketing Hub and Marketo Engage, do not assume that an approval status is a hard stop. In the firm's actual edition and configuration, test whether approval blocks scheduling or launch, what happens after a content change, and whether the record retains the approver, approved version and timestamp.

Apply the same checks to Salesforce Marketing Cloud, Braze and Klaviyo. Verify the behaviour in the firm's actual edition and configuration, including whether approval blocks release and whether changes to approved content require sign-off again.

For Dotdigital and Force24, verify the same points in the firm's actual edition and configuration. If approval is managed in a linked system, make the platform record point to it so the sign-off can be retrieved with the campaign evidence.

Reviewing evidence records and audit trails

An evidence record answers three questions: what was approved, who approved it, and what actually sent. The audit trail links those three.

Store the approved copy as an immutable version. If the platform allows automated copy changes, the approval must be re-run. A disclosure policy that covers automated copy changes should say who re-approves and how fast.

The record should include the campaign ID, the approver name, the approval timestamp, the send timestamp, and the audience count. It should also include the exact personalisation rules used at send time.

A screenshot is not an audit trail. Screenshots carry no metadata, cannot be searched, and are easy to alter. Export the record from the platform as structured data and keep it in a system with access controls.

The record needs a retention rule before the first campaign runs. Decide who owns the store, who can read it, and how it is deleted when the period ends. A record kept past its retention date is its own risk.

Service standards tied to harm rather than round numbers help here. If a campaign can cause client harm, the evidence record should be more detailed, not less.

Retention periods are set by your firm's policy and the FCA's record-keeping rules in SYSC 9, which require records of MiFID business to be kept for at least five years. Other business follows the principle of keeping records for as long as they are relevant. Confirm the period that applies to your firm.

The record should be retrievable by campaign ID, by approver and by date. If a review asks for every promotion signed off by one person in a quarter, the platform should answer that in one query.

How to compare approval controls across platforms

Run the same test campaign in each product and in the edition and configuration under consideration. Follow intake, build, approval and release; attempt to schedule before approval, then change approved copy and check whether approval is required again.

Record whether each platform blocks release without approval, how it handles unanswered requests, and whether a rejection returns the draft with the reviewer's reason attached. These checks show how the workflow behaves, rather than relying on a status label.

Inspect each platform's evidence record or export for the approved copy version, approver, timestamp, send log, audience and personalisation rules. If some information sits in a linked system, check that the campaign record points to it.

Test routing rules for delegated limits and role changes. When an approver leaves the firm, check whether past records remain readable and still show the role as well as the name.

Do not infer a capability from a product name or an approval status. Record the edition, configuration, test performed, result and evidence retained for each platform.

Compare the observed controls and any gaps against the firm's approval requirements. If approval depends on a separate tool, check that the campaign record links to the sign-off evidence.

For wider selection criteria, see the software selection guide; assess approval controls separately from other platform preferences.

The twelve-point approval-gate checklist

Run every check on each platform you are reviewing and record pass, fail or workaround, with the edition and the date tested.

Checks 1, 2 and 5 decide whether a platform can carry a regulated promotion on its own. A fail on any of them means a separate release control must sit outside the platform. Treat failures on the other nine as gaps to close or document before the first live send.

Who signs off, and what the sign-off record contains

The sign-off must be named. A team inbox is not a sign-off. The record should show the individual, their role and the time.

The sign-off record should contain:

If the platform cannot store all seven, store the missing items in a linked system and note the link in the record. The record must be retrievable in one place during a review.

A senior manager can delegate sign-off, but the delegation should be in writing and in the record. The FCA expects firms to know who approved what.

Delegation should also have a limit. A delegated approver might cover routine newsletters but not a new product launch. Write that boundary into the platform's routing rules so the wrong person cannot approve the wrong campaign.

When an approver leaves the firm, their past records must remain readable. Store the role as well as the name, so the record still makes sense two years later.

Testing the workflow before the first live send

Pre-live workflow testing is the step most firms skip. Test with a seed list that includes internal addresses and a small group of consenting colleagues.

Test these paths: approval rejection, approval timeout, personalisation fallback, unsubscribe link, and a send to a suppressed address. Each test should produce an evidence record.

Test the record as well as the send. After the seed send, export the evidence record and check that the approver, version and timestamp all appear correctly. A record that cannot be exported is not an audit trail.

If the test fails, fix the workflow, not the record. A patched record is worse than a delayed campaign.

Run the test again after any platform change. A new integration can break the approval gate without warning.

Keep a short test log with the date, the tester and the result. That log is the evidence that the control worked before the campaign went live.

Common questions