#Marketing Cloud90 debatiendo

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.

Hi @Guilherme Sequine, here are some of the practices I see most customers adopting: 

1. SMS: if you have sender codes for Production and Dev use, set up both in Production first, then refresh the sandbox. A code can only be active in one org at a time, so both live in Production but only the real one is active there; in the sandbox, deactivate the real one and activate the test one.
2. Email: sending domains, From addresses and tracking domains don't copy to sandboxes and can't be deployed between orgs. To send from your own domain, each sandbox needs its own authenticated sending domain; if your sandbox is long lasting and it is relatively easy for you to set a DKIM on your / your customer's domain, a separate subdomain per sandbox keeps it clean. If not, I believe you can activate the "Use a substitute email address for unverified domains" in Setup > Deliverability. It is worth a quick test.
3. Data 360: provision in Production first, then activate Data 360 in each sandbox separately (if the sandbox exists before Data 360 on Production, activate Data 360 in Production and then refresh the sandbox, or use Match Production Licenses, which can take up to 24h). Connections copy over from Production but come across deactivated, so you need to activate each one. The CRM home connection switches to point at the sandbox org automatically when you activate it.

There are a lot of helpful videos at this link, including the first one that talks about deployment back to Production: https://help.salesforce.com/s/articleView?id=mktg.mktg_videos.htm&type=5

I hope this helps :-)

@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.

Good question, and one I'd like to answer properly, but the honest answer is that the shape of what you build changes completely depending on a few things you haven't told us yet. So let me ask rather than guess. 

First, a snag in the input list. You've got conversion rate, AOV and revenue generated as separate inputs. Those can't all be independent, either revenue is derived (contacts × CR × AOV) or it's measured from actual order data. If both, the calculator can disagree with itself on day one. Which is it meant to be? 

Is this a forecast or a scorecard? A pre-launch business case with sliders and ranges, and a post-launch "what did this actually earn us" report, are two different artefacts. Same formulas, completely different data sources and completely different build. Most of these tools get abandoned because they try to be both. 

Are your journeys always-on or campaign-shaped? For an always-on journey, ROI isn't a number, it's a curve. Contacts keep entering, conversion rate drifts, build cost is sunk and shrinking per contact over time. You'd need entry cohorts and a payback view, not a single figure. 

Do you already have holdouts running? This is the big one. Without a control group you're not measuring incremental anything, and no amount of formula design fixes that. If you do have them: are they persisted per contact, or re-rolled with Random Split on each entry? And is there a global holdout as well as per-journey ones? (Per-journey lifts don't sum to portfolio lift, and the gap matters.)

Where do revenue and cost data actually live? MCE has neither revenue nor margin nor cost of goods. That pushes the actuals half of this toward Data 360 / your warehouse / Tableau, with MCE contributing engagement and holdout membership. Is that available to you, or are you constrained to build inside MCE? 

Who owns the cost-avoidance assumptions? Cost avoidance is where business cases go to get manufactured. If Finance hasn't signed off on "cost per deflected call," it's a soft number and should be flagged as one. 

One last thing, said kindly: most of this question isn't really MCE-specific. Incrementality design, control-group methodology, margin vs revenue, cost-avoidance taxonomy: that's marketing measurement, and it would be true if you were running Braze or a spreadsheet. The genuinely MCE-shaped slice is narrow: how to persist a holdout flag so it survives re-entry, how to get engagement data out into something that can join it to orders, and whether a Cloud Page + assumptions DE is a sane place to put the front end. Happy to go deep on that slice here, since that's what this group is good at. 

For the measurement-design half you'll get better answers where the analytics and architecture folks hang out. The Marketing Architects group, or a Data 360 / Tableau group. Genuinely worth cross-posting; it's a good question, just a two-venue one. 

Tell me which of these apply and I'll happily go into the formulas with you.