Consent Requirements Worksheet
Capture what consent you need, where it is collected, how it is evidenced and which system owns it, before you design consent in Salesforce and Marketing Cloud.

Consent designs go wrong when the technical build starts before anyone has written down the requirements. This worksheet collects those requirements in one place so your legal or privacy adviser, marketing team and Salesforce architect are working from the same facts. Complete it before you design objects, fields, sync rules or preference pages.
Part 1: Regimes and markets
List every country or region where you market to people, and the rules your adviser says apply. Common examples include the EU and UK GDPR with their electronic marketing rules, India's Digital Personal Data Protection Act, CAN-SPAM in the United States and CASL in Canada. For each, note whether marketing generally needs prior opt-in or can rely on another basis, and any channel-specific rules for SMS, calls or messaging apps.
Part 2: Purposes and channels
Consent is rarely one checkbox. Record each purpose separately and the channels it covers. Purposes your team cannot explain to a customer in one sentence are usually too broad.
Purpose and channel matrix (example)
| Purpose | SMS | Phone | Basis noted by adviser | |
|---|---|---|---|---|
| Product news and offers | Opt-in | Opt-in | Not used | Consent |
| Event invitations | Opt-in | Not used | Not used | Consent |
| Service and account messages | Always sent | Where needed | Where needed | Contract or legitimate interest |
| Surveys and research | Opt-in | Not used | Not used | Consent |
| Partner offers | Not used | Not used | Not used | Out of scope |
Part 3: Capture points
| Capture point | Purposes captured | Wording version | Lands in |
|---|---|---|---|
| Website newsletter form | Product news | v3, 2026-04 | CRM Contact or Lead via form handler |
| Checkout page | Product news, surveys | v2, 2026-01 | Commerce platform, then CRM |
| Event registration | Event invitations | v1, 2025-11 | Event tool, then CRM |
| Call centre | Any, recorded by agent | Script v4 | Service Cloud |
| Preference centre | All marketing purposes | v3, 2026-04 | CRM, synced to Marketing Cloud |
Part 4: Evidence and withdrawal
- 01
Evidence fields
For each consent, decide what you store: status, timestamp, capture point, wording version, and how the person was identified. If you cannot show how consent was given, assume you cannot rely on it.
- 02
Withdrawal routes
List every way someone can withdraw: unsubscribe links, preference centre, reply STOP, call centre, email request. Each route needs a defined path into the system of record.
- 03
Timing
Agree with your adviser how quickly withdrawals must take effect, then design sync frequency to meet it. Some channels need near real-time updates.
- 04
History
Decide whether you keep a history of changes or only the latest state. A history makes audits and disputes far easier.
- 05
Retention
Define how long consent records are kept after someone withdraws or is deleted, and who approves deletion.
Part 5: System of record and sync
Name one system of record for each purpose. Everything else is a copy. Then map how consent moves:
- Salesforce CRM: the consent data model includes objects such as Individual, Contact Point Type Consent and Data Use Purpose, or you may use simpler custom fields. Record which approach you will use and why.
- Marketing Cloud Engagement: All Subscribers status, publication lists and your own consent data extensions all play a part. Decide which one each send checks.
- Account Engagement: opt-out and email preference settings on prospects, and how they sync with CRM.
- Data Cloud: which consent data is ingested and how segments and activations filter on it.
Note conflicts explicitly. If a person unsubscribes in Marketing Cloud but the CRM still shows opted in, which wins, and how does the other system learn about it?
Part 6: Sign-off
Record who reviewed the worksheet (privacy, marketing, platform owner), the date, and the trigger for the next review, such as a new market, a new channel or a new capture point.
For design patterns, see consent synchronisation across CRM and marketing, the self-service preference center blueprint, designing consent in Marketing Cloud Next and contact deletion and data retention.
Turning requirements into a consent design?
We can translate your completed worksheet into a data model, sync rules and preference experience across Salesforce and Marketing Cloud.




