Automating messaging consent in Salesforce is essential for maintaining compliance and scaling customer communication. In this guide, you’ll learn how to auto-create OPT-IN Messaging Consent records using a Record-Triggered Flow, eliminating manual work while ensuring accurate, real-time consent capture.

If you’re searching for a reliable way to automate consent tracking in Salesforce without Apex and make your org compliance-ready, this guide walks you through the exact architecture and implementation.

Consent management is a critical component of modern CRM systems, especially when working with:

• Marketing Cloud Growth 
• Data Cloud 
• GDPR / CAN-SPAM compliance requirements 
• Automated subscription management

Here’s how to build a Record-Triggered Flow on Contact that automatically creates a Messaging Consent record when a new Contact is created.

This solution ensures:

✔ Automated consent creation

✔ Compliance-ready configuration

✔ Scalable architecture

✔ No manual intervention

We’ll break down every element of the flow and explain what it does and why it’s needed.

Flow Architecture Overview

Flow Type:

Record-Triggered Flow

Object:

Contact

Trigger:

When a record is created

Optimize For:

Actions and Related Records

Step 1: Record-Triggered Flow Configuration

Why Use Record-Triggered Flow?

We want consent automation to happen:

• Immediately when a Contact is created 
• Without manual clicks 
• In a scalable and maintainable way 

Using a Record-Triggered Flow ensures:

• Automatic execution 
• No dependency on Apex 
• Admin-manageable logic

Step 2: Decision Element – “Check Email Present”

What This Does?

This decision checks the following:

Is email populated?

If:

• Email exists → proceed 
• Email is blank → end flow 

Why This Is Important?

Creating Messaging Consent without an email makes no business sense because:

• Consent is tied to a communication channel 
• Email is required as a contact point 
• MessagingConsent requires ContactPointValue 

This protects:

• Data quality 
• Compliance accuracy 
• System integrity 

Step 3: Get Created Contact

What Does This Do?

Fetches the newly created Contact record again.

Why Not Just Use $Record?

Although $Record contains data, sometimes we explicitly fetch the record to:

• Ensure latest committed data 
• Access related fields safely 
• Keep architecture structured for expansion 

This is especially useful if future logic grows.

Step 4: Get Email Engagement Type

What This Does

Retrieves the Engagement Channel Type for Email.

This likely queries:

• Communication Subscription Channel Type 
• Email-related engagement configuration

Why This Is Required

Messaging Consent requires:

CommunicationSubscriptionChannelType

Without this:

• Consent record cannot be created 
• System doesn’t know which channel to apply consent to

This step identifies:

Which communication channel are we creating consent for?

Step 5: Get Subscription Id

What This Does

Retrieves the relevant subscription records associated with the communication type.

Why This Step Is Critical

A single Contact may have:

• Multiple subscription types 
• Multiple marketing programs 
• Multiple communication channels 

Instead of hardcoding a single ID, we dynamically fetch:

✔ All relevant subscriptions

✔ Make the solution scalable

This prevents future maintenance issues.

Step 6: Loop Element (Loop 1)

What This Does

Loops through the collection of subscription records retrieved earlier.

Why Use a Loop?

Because:

• There may be multiple subscription IDs 
• Consent must be created for each subscription 
• Hardcoding would break scalability

Loop allows:

✔ Dynamic processing

✔ Bulk-safe design

✔ Enterprise-grade flexibility

Step 7: Messaging Consent Creation – Exact Implementation (As Configured in This Flow)

After retrieving the required subscription records and looping through them, we use the standard Salesforce action:

MessagingConsentV2.MessagingConsent

This action is responsible for creating a Messaging Consent record for each subscription associated with the Contact.

Below is the exact configuration used in this flow.

Formula Resource Created: ConsentId

Before configuring the Messaging Consent action, a Formula Resource was created.

Resource Name:

ConsentId

Data Type:

Text

Formula:

{!$Record.Email} & “#” & {!Loop_1.Id}

Why This Formula Is Used

This formula dynamically generates a unique identifier by combining:

• The Contact’s Email 
• The Subscription Id from the Loop
  

Example output:

john.doe@email.com#0XlPs00000000XtKAI

Why This Matters

This ensures:

• Each consent record is uniquely identifiable. 
• No duplicate consent creation for the same email + subscription. 
• Proper traceability for compliance.
  

This is an important design decision to maintain uniqueness in consent records.

MessagingConsentV2.MessagingConsent – Field Configuration

Now let’s break down the exact field mappings configured in the action.

CommunicationSubscriptionChannelType

Mapped Value:

Communication Subscription Channel Type ID

This value comes from the Get Records step that retrieves the subscription channel type.

Purpose:

This identifies which communication channel (Email in this case) the consent belongs to.

Without this, Salesforce cannot associate the consent with the correct subscription channel.

ConsentCapturedDateTime

Mapped Value:

Running Flow Interview → CurrentDateTime

Purpose

Records the exact timestamp when consent is captured.

This is essential for:

• Audit tracking 
• Compliance validation 
• Legal reporting requirements

ConsentId

Mapped Value:

ConsentId (Formula Resource)

Purpose

Uses the dynamically generated composite key:

Email + “#” + SubscriptionId

This guarantees uniqueness for each consent record.

ConsentStatus

Value:

OPT_IN

Purpose

Defines the contact’s consent status.

In this implementation:

Every new Contact with an email is automatically marked as OPT_IN for the relevant subscription.

ContactPointValue

Mapped Value:

Triggering Contact → Email

Purpose

Defines the actual communication value of the consent.

Since this is an email-based consent:

• The Contact’s Email field is used as the contact point.

UpdatedTime

Mapped Value:

Running Flow Interview → CurrentDateTime

Purpose

Ensures that:

• The consent record has a proper last updated timestamp. 
• The record remains audit-compliant.

Note: In this implementation:

• PartyId was not included in the action.

• ConsentCapturedSourceName was not included.

• ConsentCapturedSourceType was not included. 

Only the required and relevant fields were mapped based on your actual configuration.

How the Loop Works in This Architecture

1. Get Subscription Id retrieves all relevant subscription records. 
2. Loop 1 iterates through each subscription. 
3. For each subscription: 
   • A unique ConsentId is generated. 
   • MessagingConsentV2.MessagingConsent action is executed. 
4. The flow completes after processing all subscriptions.

This ensures scalability and supports multiple subscription records per Contact.

By implementing this flow-based approach, you can streamline consent management, improve data accuracy, and stay compliance-ready without using Apex. It’s a scalable, no-code solution for managing OPT-IN consent efficiently in Salesforce.

No Data Found.