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.
The Consent Audit Trail is an object in Data Cloud that records a row for every consent change. Unlike the Communication Subscription Consent DMO (which stores current status and is updated in place), the Audit Trail is append-only: rows are inserted, never updated, so it serves as the historical record of all opt-in / opt-out events for a given Contact Point value and Communication Subscription Channel Type.
|
Field |
Description |
|---|---|
|
Id |
Unique system identifier for the audit trail record. |
|
TimeStamp |
Date and time the audit row was written (when the change was recorded in the system). |
|
ConsentCaptureSourceDateTime |
Date and time the consent decision was actually captured, as provided by the calling application. This can differ from TimeStamp when consent was collected earlier and synced in later. |
|
ConsentStatus |
The resulting consent status after the change (for example, Opt In or Opt Out). |
|
PassedConsentStatus |
The consent status passed in by the calling application for this update. |
|
ConsentUpdateAction |
The action that triggered the update (for example, the create or update operation applied to the consent record). |
|
ContactPointValue |
The contact point the consent applies to, such as the email address or phone number. |
|
CommunicationSubscriptionChannelTypeId |
Identifier of the communication subscription channel type the consent record is tied to. |
|
ChannelType |
The channel the consent applies to (for example, Email or SMS). |
|
PartyId |
Identifier of the individual (party) the consent record belongs to. |
|
SenderId |
Identifier of the sender associated with the consent record. |
|
ConsentCapturedSourceType |
The type of source that captured the consent (caller-provided source attribution). |
|
ConsentCapturedSourceName |
The name of the source that captured the consent, such as the form, flow, or application name (caller-provided). |
|
ConsentCapturedSourceDetails |
Additional details about the source that captured the consent (caller-provided). |
There's no dedicated UserId / ActorId / ModifiedById field; this is by design for the current schema. The closest fields are caller-provided source attribution (ConsentCapturedSourceType, ConsentCapturedSourceName, ConsentCapturedSourceDetails, SenderId) — populated only if your calling application sets them at ingestion time. If you need actor-level attribution for compliance, populate ConsentCapturedSourceName and ConsentCapturedSourceDetails from your flow, form, or integration with whatever actor identifier you can supply.
Marketing Cloud consent is intentionally agnostic of PartyId (see "Why is PartyID not used?"). Consent is keyed on the Contact Point value plus the Communication Subscription Channel Type ID, so PartyId is written blank by design — even when the upstream record is a Lead or Contact. To stitch audit rows back to a Lead or Contact for reporting, join ContactPointValue from the audit object to the ContactPointEmail or ContactPointPhone DMOs, which carry the PartyId mapping.
Not out of the box today. A per-person consent history component on the Contact or Lead record is a known request and is on the roadmap (there is no committed release date).
The audit object is insert/upsert-only — there's no self-service feature to delete individual rows.
Options:
GDPR Right to be Forgotten — use the Consent API "ShouldForget" endpoint on the Individual. This flags the individual, and an asynchronous process performs the deletion across the Individual DMO and related objects. Deletion typically takes hours and is reprocessed at 30, 60, and 90 days for full coverage. Deletion is permanent. See: Data Deletion Request and the Consent REST API reference.
Bulk deletion (for example, undoing a bad initial import) — there's no feature in the user interface to complete these; please engage Salesforce Support.
Right to Be Forgotten Policies in Privacy Center — a separate framework; confirm which applies based on your edition. See: RTBF Policies.
Reporting is supported: you can query the consent and audit objects via Data Cloud's Query Editor and Data Explorer to build compliance and operational reports. Segmentation on consent status isn't supported out of the box today (use the Calculated Insight workaround instead see — the Segmentation section).
Rejected rows commonly indicate one of these causes:
Wrong object mapping — the audit object is mapped to the wrong target, creating phantom rows. Re-check your data stream mapping.
Date-format issues — an unsupported timestamp format for the consent-captured date can cause the intended write to be skipped while an audit row is still written. Validate timestamp format before ingesting.
Status case mismatch — sending "OptIn"/"OptOut" instead of "OPT_IN"/"OPT_OUT." Use the Create Consent action, which produces correctly formatted values.
If issues persist after checking these, engage Salesforce Support.
005389884

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.