#Marketing Cloud90 discussing

Hi Guilherme, good questions. Building and testing in a sandbox is the right approach for journeys, segments, content and flows, but treat channel setup as per-org configuration rather than something you deploy. 

1. WhatsApp: The WhatsApp sender is tied to a phone number registered with Meta under a WhatsApp Business Account, and a number can only be active in one place at a time. Use a separate test number (or Meta's test setup) in the sandbox for development and testing, and plan to connect the real business number directly in production. You will repeat the channel connection and template approval steps in production, so document them as a go-live runbook. 

2. Email: Sender domain/subdomain authentication (SPF/DKIM records) is configured per org, so you set it up again in production. For the sandbox, use a dedicated test subdomain so test sends never touch your production sending reputation. IP/domain warming only matters where you send real volume, which is production. Sandbox sends are low volume to internal test addresses, so there is nothing to warm there. 

3. What does deploy: segments, journeys/flows, content and data model changes can move through your normal deployment path (change sets, DevOps Center or a CLI pipeline), but check the current Marketing Cloud Next documentation for which components are supported metadata, as coverage has been changing release to release. 

Tip: build a go-live checklist early that lists every manual production step (WhatsApp number connection, template approvals, domain DNS records, consent/compliance settings, warming plan). DNS changes and Meta approvals can take days, so start them in production in parallel with sandbox testing rather than after sign-off.

Hi @Lukas Lunow

This gets easier to create an approach, when we look at how each piece works underneath. Not done personally, but this is how i would approach this: 

1. Sending works per row, so create the rows you want sent. MC Next sends one email per record that reaches the send step. If you want one email per account relationship, you need one row per Account Contact Relationship. Build a DMO with a Data Transform, keyed on the ACR Id, with the Contact Id, email and the account fields you need (company name, figures, role) on that row. Two relationships means two rows, which means two emails.
2. Personalization reads from the record being sent, so put the account data on that record. The data graph gets ambiguous when one person has several accounts attached, because nothing tells it which one to pick. If each ACR row already carries its own account data, the merge fields just read from that row and the output is deterministic.
3. Identity resolution is for the person, not the relationship, so let it do only that. Unified Individual exists to collapse the same human into one profile, which is exactly what you want for consent on email. Keep Contact Id as a Party Identification and match on email. Keep account-specific attributes off the Individual, so they never compete in the unified profile. Consent and suppression stay at the person level, and the send grain stays at the relationship level.

The main thing I’d validate is how cleanly MC Next lets you send off a relationship-level DMO while still checking consent on the linked Unified Individual. We can prototype with one contact on two accounts before rolling out. 

Hi @Mradul Srivastava

Not sure if helpful as our issue was with Microsoft, but we had a similar situation earlier this year. Everything our end was the same as it's always been but suddenly we had a lot of hard bounces to Microsoft email addresses only.  

The cause was an IP restriction on their end due to another sender in our shared IP pool. I was able to get this restriction removed with the help of Salesforce and Microsoft support teams.

@Guilherme Sequine Saquei! 

O evento chegar no flow e no Data Cloud confirma que o carrinho abandonado está entrando. A vitrine é outro passo: ela só repete os produtos quando o Repeater tem uma fonte, e cada campo de dentro (imagem, nome, preço e link) é merge field dessa mesma fonte. Com o layout estático, o teste envia o e-mail e a vitrine vem vazia ou fixa. 

O data graph só alimenta a vitrine quando ela está em Data Graph Attribute. Nesse caso ele precisa incluir o DMO dos itens do carrinho, no caminho Unified Individual → Unified Link Individual → Individual → itens, com nome, preço, imagem e URL marcados. O e-mail usa o graph padrão do Setup (Customer Engagement), salvo se tiverem colocado outro na própria mensagem. Esse graph atualiza na agenda, então o carrinho pode já estar no Data Cloud e ainda não estar disponível para a vitrine. Um graph só de perfil envia o e-mail e não tem linha de produto para repetir. 

Para esse teste, liguem a vitrine no evento, que é o payload que vocês já validaram. No e-mail, aba Data Sources, adicionem o evento de carrinho abandonado (o mesmo do flow). No Repeater, definam o Repeater Source nesse evento, nos itens do carrinho. Dentro da vitrine, a imagem entra como Merge field, e nome, preço e URL do botão também, todos dessa mesma fonte. Salvam e fazem o preview com a pessoa que gerou o evento. Se nome e preço aparecerem e a imagem continuar em branco, incluam o domínio da imagem em Setup → Trusted URLs.

Hi @Swetha reddy

, 

Even though Salesforce Marketing Cloud (SFMC) automatically blocks emails to anyone marked "Unsubscribed" in the All Subscribers list, relying solely on that list won't remove them from the Journey canvas. If you want contacts to leave the journey when they officially opt out, or if consent comes from an external CRM, use one of the two approaches below.

Option 1: Use Journey Exit Criteria via Contact Builder (Recommended)

Journey Builder cannot read the All Subscribers list or Publication Lists directly in Exit Criteria. It requires a linked Data Extension under Contact Data.

1. Create a Consent / Unsubscribe Data Extension (DE)

• Include fields such as SubscriberKey (Primary Key) and ConsentStatus or Status.

2.Keep the DE Updated Automatically

• If consent is tracked inside SFMC: Set up a scheduled Automation Studio query targeting the _Unsubscribe data view or _Subscribers data view to populate this DE regularly (e.g., hourly).
• If consent comes from Salesforce CRM or an external system: Use Synchronized Data Extensions or an incoming API/file import to keep this DE up to date.

3. Link the DE in Contact Builder

• Go to Contact Builder > Data Designer.
• Create an Attribute Group and link your Consent DE to the Contact record using Contact Key = SubscriberKey (1-to-1 relationship).

4. Set the Exit Criteria in Journey Builder

• Select Contact Data (not Journey Data).
• Configure the rule: Consent DE -> Status equals 'Unsubscribed'.
• How it works: Whenever a contact finishes a wait activity, Journey Builder evaluates the Exit Criteria. If their record in Contact Data shows they opted out, they immediately exit before the next email is sent.

Option 2: Suppress via Exclusion Script (Quick Workaround)

If you do not want to configure an Attribute Group in Contact Builder, you can keep contacts inside the journey path but prevent the emails from sending:

1. Maintain an updated Unsubscribed_DE containing SubscriberKey.
2. Add an Exclusion Script to each Email Activity in the journey:

Code snippet

ROWCOUNT(LOOKUPROWS("Unsubscribed_DE", "SubscriberKey", AttributeValue("_SubscriberKey"))) > 0

If their key appears in the unsubscribe list, SFMC skips sending the email.

How to Test This with Fictional Test Customers

Because your fictional customer is not in All Subscribers yet:

1. Add them to All Subscribers first: Perform a simple test send (or standard User-Initiated send) to your test record so SFMC registers the SubscriberKey and email address in All Subscribers.
2. Enter the Journey: Inject the test subscriber into your Journey.
3. Trigger the Unsubscribe Mid-Wait: While the contact is paused in the Day 0–3 Wait activity:

• Change their status in your Consent DE (or in All Subscribers / your CRM).
• Run your update query/automation so the linked Contact Data DE reflects Status = Unsubscribed.

4. Verify the Exit: When the wait timer expires, inspect the Journey canvas health and history. The contact will show as Exited via Exit Criteria rather than moving to the next email.