Governance has an image problem in marketing teams, and it is deserved. Done badly it means a change-approval board that takes three weeks to sign off a subject line. Done well it is almost invisible: the team ships faster because nobody has to stop and wonder whether they are allowed to.
For a Salesforce marketing estate, four areas carry nearly all the risk. Get these right and the rest can stay lightweight.
Key takeaways
- Consent is an architecture decision, not a checkbox. Model it once, centrally, and let every channel read from it.
- Access control failures in marketing are usually export-shaped, not edit-shaped.
- A sandbox with no representative data is a sandbox nobody uses — which means production becomes the test environment.
- Marketing change needs a release process sized to the risk, with a two-tier split between content and configuration.
- Write down who owns each decision. Most governance incidents are ownership gaps rather than rule violations.
1. Consent and preferences
The single most common structural mistake: consent stored per channel, per system, per campaign tool. One flag in the CRM, another in the email platform, an unsubscribe list somewhere else, and a preference centre that writes to only one of them. Every one of those is a place where a withdrawal can fail to propagate — and under GDPR, a failure to propagate is the violation.
The target architecture is simple to state and takes real work to reach:
- One authoritative store per consent type. Email marketing, SMS, phone, profiling, and any lawful-basis distinctions your legal team requires. Each has one home.
- Every channel reads from it at send time. Not a nightly copy — a copy is a window during which you can send to someone who has just opted out.
- Every capture point writes to it, with the source, the timestamp and the exact wording the person agreed to. “When did they consent and to what” is the question a regulator asks, and “we do not store the wording” is not an answer.
- Withdrawal is honoured immediately and everywhere, including in journeys already in flight.
- One preference centre that reflects the authoritative store, rather than a second opinion about it.
The in-flight journey problem
Someone unsubscribes on Tuesday. A journey they entered on Monday has a three-day wait and sends on Thursday. Whether that send happens depends entirely on whether the send step re-checks consent or trusts the entry-time evaluation. Test this specific scenario in every orchestration tool you run. It is the most common way a technically compliant organisation sends a non-compliant email.
Two further points that come up in every DACH engagement. Double opt-in should be modelled as a state — pending, confirmed, expired — not as a boolean, because “we sent the confirmation and they never clicked” is a distinct situation from “never asked.” And retention needs a rule: consent records and engagement history do not get to accumulate forever just because storage is cheap.
2. Access: the export problem
Marketing access reviews usually focus on who can edit. In practice the marketing-specific risk is who can extract. A user with read access to contact data and permission to run and download reports can walk out with the customer database, and every tool in the stack offers a different door: report export, list view export, data extension export, integration user credentials, API-connected spreadsheets.
A workable model:
| Role | Should be able to | Should not be able to |
|---|---|---|
| Campaign builder | Build and send within an assigned business unit or workspace; use audiences | Export contact-level data; change consent; alter shared assets |
| Marketing ops | Configure automation, segments, integrations; deploy changes | Bypass approval on production sends without a second pair of eyes |
| Analyst | Query and report, ideally on aggregated or pseudonymised views | Bulk-export raw personal data as a routine act |
| Agency or contractor | Exactly what the current statement of work requires, time-boxed | Retain access after the engagement ends |
| Integration user | The specific objects and fields its integration touches | Log in interactively; hold a broad administrator profile |
Two habits make this durable. Run a quarterly access review — a short list of who has what, reviewed by a human who knows the team, is worth more than an elaborate permission model nobody revisits. And give every integration its own named user, so that when something writes bad data at 3am you can tell which system did it.
3. Environments
Marketing teams test in production more than any other function, for one reason: the sandbox has no usable data. A sandbox with three contacts and no engagement history cannot validate a segment, a journey or a personalisation rule, so people quite rationally build in production and hope.
The fix is not more sandboxes; it is one sandbox that is actually representative:
- Seeded with enough data to exercise real logic — a subset that includes your edge cases, not a random sample of the easy ones.
- Anonymised, and provably so. Personal data in a sandbox that agency users can access is a breach waiting for an audit.
- Email sending contained. A sandbox that can reach real inboxes will, eventually, on a Friday afternoon.
- Refreshed on a known cadence, so people trust it and build the habit of using it.
Alongside that, keep a small set of production test records — real records, flagged as test, excluded from every report and every audience by a rule rather than by convention. Every team needs a safe way to see what a customer actually receives.
4. Release management for marketing change
Applying full software release discipline to every campaign email is how governance gets its reputation. Applying none of it to a change in lead routing is how you lose a month of leads. Split the difference by risk.
Tier one — content. Emails, landing pages, copy, images, individual campaign setup. Peer review, a real send test to a seed list, and go. Hours, not days. No ticket queue.
Tier two — configuration. Anything that changes behaviour across campaigns: scoring models, routing rules, automation, data model changes, consent logic, integrations. This path needs four things: built and tested in sandbox first, a written description of what changed and why, a named owner, and a rollback plan. Not a committee — a checklist.
The rule that keeps it honest: the tier is determined by blast radius, not by urgency or seniority. “We need this today” is a scheduling input, not a reclassification.
Keep a change log people actually read
One page, newest first: date, what changed, who did it, why, how to undo it. When a metric moves unexpectedly, the first question is always “what changed last week,” and a five-line log answers it in thirty seconds. Automated audit trails are useful for forensics; a human-written log is what actually gets read in the moment.
Ownership: the part most teams skip
Almost every governance incident I have seen traces back to an unowned decision rather than a broken rule. Write down, on one page, the named owner for: the consent model, the data model, the scoring model, the sandbox refresh, the access review, the integration credentials, the deliverability configuration, and the change log itself.
“Owner” means the person who decides and who gets asked, not the person who does all the work. For a small team it may be the same name eight times, and that is fine — the value is that it is written down, so when that person leaves, the gap is visible on day one rather than in month four.