Note: This article is a companion article for the Consent Management: Frequently Asked Questions resource. Check that article out for additional details and other frequently asked questions.
Consent is stored in Data Cloud in the Communication Subscription Consent (CSC) Data Model Object (DMO).
Use one of these supported methods. Each one updates consent correctly so that it is honored at send time:
1) Manually
Bulk import of consent data (CSV, up to 50,000 rows per file) — best for one-time loads
Manual updates in the Consent Status component on individual records.
2) End user updates
Unsubscribe URLs in emails.
Preference Page submissions
Opt outs from SMS/WhatsApp.
Landing Page form submissions, when paired with an Automation Event-Triggered Flow and Consent Request action
3) Specific Flow actions
Consent Request Action (also labeled Create Consent) in Automation Event-Triggered Flows (includes Form-Triggered Flows) or On-Demand Flow
Create Consent Action in Data-Cloud Triggered Flows
Avoid these methods. They can result in consent values that are not honored correctly at send time:
Data Stream mapped directly to the Consent Data Lake Object (DLO)
Data Cloud Bulk Ingestion API writing directly to the Consent DMO
Data Cloud Batch Data Transforms to update a DLO that is mapped to the Communication Subscription Consent DMO.
The legacy MessagingConsent.MessagingConsent and MessagingConsentV2.MessagingConsent flow actions (they write directly to the DLO)
If you use any above methods to update consent:
Consent may not be respected correctly during messaging sends even though it appears that updates were saved in the Communication Subscription Consent DMO.
In some cases, this means that an email may not be sent even though an email address appears opted in.
In other cases, this may mean that an email may be sent inadvertently, even though the email address appears opted out.
The consent in the Communication Subscription Consent DMO may not align the consent showing on individual records in the Consent Status component.
Re-issue the consent change through a supported method — most commonly a Data Cloud-Triggered Flow that calls the Create Consent action.
You could incur additional Data Cloud Data Services Credits charges due to incorrectly mapped fields.
No. These legacy actions are not supported for consent in Marketing Cloud Next and should not be used. Use the Create Consent/Consent Request action instead. If you need to create or update consent based on a CRM record change, use an Automation Event-Triggered Flow with the "Prospect, Lead, Contact or Related Record Change" event type from the Event Library.
Currently available only in the following flow types:
Data Cloud-Triggered Flows
Automation Event-Triggered Flows
On-Demand Flows
For a Lead/Contact create-or-update use case, use an Automation Event-Triggered Flow with the "Prospect, Lead, Contact or Related Record Change" event. Support for future flows types is being considered on the roadmap.
Use the Create Consent/Consent Request action in a Data Cloud-Triggered Flow, On-Demand Flow, or Automation Event-Triggered Flow (with the "Prospect, Lead, Contact or Related Record Change" or "Form Submission" events). See: Create Consent Marketing Flow Element
No, there is no limit to the number of Communication Subscriptions for Marketing Cloud Next.
Writing directly into the Consent DMO from an external system is not a supported path. Route consent writes through a supported method (see above) so that consent is honored at send time.
For commercial sends, Marketing Cloud Next requires consent expressed through the Communication Subscription Consent model; there is no supported path to drive sends from custom flag fields. Custom flags can feed the standard model via Flows, but they do not replace it.
Understanding Consent Concepts in Marketing Cloud Next
Troubleshooting Marketing Flows That Contain the Create Consent Action
Consent Management: Frequently Asked Questions
005316463

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.