* Marketing Cloud Growth & Advanced *

Hi Michael - All the MCN components can be deployed through Change Sets as well as third-party tools like Copado and Gearset. Uploaded PDFs compeonent and Custom Report and Report type cannot be deployed through Copado, so they need to be created manually in the higher environment (target environment). But all other components can be deployed easily through Copado and Change Sets. I have shared all the detailed information related to MCN and Data Cloud Data Kits in my first comment, and even all the issues you may face during deployment are also mentioned there.

Thank you for the confirmation.  

We added two hidden fields to our MCA embeded form (WebDeviceId__c, Conversion_Page__c). Does the embed support prefilling them from the host page’s URL parameters, a data attribute, or a cookie? What’s the exact syntax?  

Also, is the deviceId on the Lead enough, or do we need matching Party Identification records on both sides? 

 Our understanding is that the hidden field alone won’t merge anything. We’d need: 

• the Lead/Contact deviceId field mapped to Party Identification in the CRM stream (Identification Number = deviceId, with a fixed Identification Name and Type)
• the website connector sending a partyIdentification event from the browser with the same Name, Type, and deviceId (no email needed)
• a Party Identification match rule in the identity resolution ruleset

Hi Sheena!

Yes, this can be designed using a single preference experience, but the important part is how the subscription and channel-level consent are modeled in Marketing Cloud Next.

If the Weekly Newsletter is one subscription but can be delivered through Email, SMS, and WhatsApp, I’d keep the subscription as the common purpose and capture the customer’s preference separately for each channel. For example:

Weekly Newsletter

• Email: Opt in / Opt out
• SMS: Opt in / Opt out
• WhatsApp: Opt in / Opt out

This gives you one preference page while still maintaining channel-specific consent rather than treating one consent as permission for every channel. 

I’d also make sure the consent records are tied to the correct individual/contact and that your journeys respect the channel-specific preference before sending.

The main issue is likely the Data 360 relationship between Unified Individual and Opportunity, not the duplicate email addresses.

When segmenting by Unified Individual, Opportunity fields such as Stage are only available when Opportunity is reachable through a valid DMO relationship path.

I would check:

• Opportunity -  Unified Individual relationship in Data 360.
• Whether Opportunity fields are correctly mapped/populated.
• Avoid using Email alone as the relationship key, since the same email can belong to multiple companies/opportunities.
• If the business relationship is person → opportunity, consider using Opportunity Contact/Contact Role or Opportunity Influence as the bridge.

So the likely fix is to establish the correct DMO relationship/path, rather than changing the segment criteria.

Hi Wakana!

For Marketing Cloud Engagement+, the architecture is generally a combination of Marketing Cloud Engagement and Data 360 rather than moving everything out of Engagement.

1. Data management: You don't necessarily need to abandon your existing Marketing Cloud data extensions. Salesforce's current guidance recommends connecting Engagement to Data 360 and syncing the Engagement datasets you need. Existing MCE data extensions and CRM data can also be synced to Data 360 when you need them for richer segmentation.
2. AI segment creation: The natural-language segment experience is provided through the Marketing Cloud Next/Data 360 segmentation layer. Segments can be created using natural language with Einstein/Agentforce, based on the data available in Data 360.
3. Message delivery: The resulting audience can be activated back to Marketing Cloud Engagement, where it can be used with Engagement data extensions/Journeys for messaging. Salesforce specifically documents activating Data 360 segments to Marketing Cloud Engagement.

So I would think of the flow as:

MCE data/CRM data → Data 360 → AI/Segment Builder → segment activation → MCE Journey/Email

The exact design will depend on which existing MCE data extensions and subscriber keys you have, especially whether they can be mapped/stitched correctly in Data 360.

Hi Hanan, 

For WhatsApp integration with Marketing Cloud Advanced, I’d keep the sandbox/testing and production setup separate. You can generally use a test WhatsApp number/WABA for sandbox testing and then configure the production WABA/number separately, but make sure the required Meta/WABA assets and permissions are available for each environment. 

For a personal business account, the main limitation is usually the Meta/WABA verification and business setup requirements. If the WABA cannot complete verification, the Salesforce connection may not be able to complete either. 

I’d recommend using the Meta-provided test/sandbox setup where available for initial testing rather than connecting a personal production business number. Once the Salesforce configuration is validated, move to the production WABA and number. 

If you’re getting a specific error while connecting the WABA, share the exact error message and where the connection fails (Meta or Salesforce), and it should be easier to narrow down the issue.

Hi Akshita,

Your understanding of the data relationship looks important here. If the Contact Point Email DMO records sourced from ContactPointEmail have Party pointing to the Individual Id, while the consent-related records are keyed through the Contact Id, I would be cautious about using a Data Transform to rewrite Party and create synthetic keys unless Salesforce explicitly documents that mapping as supported. 

The safer approach would be to confirm the intended Marketing Cloud Growth consent ingestion pattern for multiple email addresses. In particular, I would verify whether custom Email fields on Contact are supported as Contact Point Email sources and whether the consent framework expects those records to originate from the standard mapped fields/DLO rather than directly from core ContactPointEmail. 

I also wouldn't recommend creating duplicate Contacts just to represent multiple email addresses. As you mentioned, identity resolution could treat the different email addresses as separate individuals depending on the matching rules. 

Since your requirement is an unlimited number of email addresses, I'd raise this with Salesforce Support and specifically ask whether a Data Transform that writes ContactPointEmail records into a DLO mapped to Contact Point Email DMO, with Party = Contact Id, is a supported consent architecture or just a workaround. 

If anyone has a working documented configuration for multiple ContactPointEmail records per Contact with Marketing Cloud Growth consent, that would be especially useful here.

@Adriano Soldi

Hi Adriano, 

For pictures, you can use the 6th recipe in this article. 

For PDF, I reckon this is not possible, even though you can store them in the CMS . For this, I'd recommend using the regular Salesforce Files instead. 

Hope this helps 😎 

#SharingIsLearning #MarketingCloudNext #AgentforceMarketing

François. 

PS : In order other Trailblazers to be pointed directly the most helpful answer, please do not forget to click “Accept this answer” below the most relevant one.