#MarketingCloudNext토론 중인 항목 20개

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.

As far as I can tell from the current documentation and community write-ups, you're not missing an element: the Email Link Click event in Wait Until Event is configured as either "any link in the email" or "one specific link", and there is no multi-select/OR list of links inside a single event condition. 

The good news is that for your requirement the fixed-wait + decision pattern gives exactly the same outcome as an early exit. In your design the only actions happen at day 7 and day 14, so a contact who clicks a qualifying link on day 2 and a contact whose click is checked on day 7 both simply receive no further emails. Exiting early only changes when the contact leaves the flow, not what they receive. So I would treat it as the correct, supported pattern: 

1. Send Email (version A). 

2. Wait 7 days (fixed duration). 

3. Decision "Clicked a qualifying link?": check the contact's email engagement for this email/flow for a click on link 1 OR link 2 OR link 3 (use the engagement/link click data available in your decision criteria, filtered to this email and the three URLs). If true, go to End. 

4. Otherwise Send Email again, Wait 7 days, repeat the same Decision. 

5. If still no qualifying click, Send Email the final time, then End. 

If your org lets you add more than one event path to a Wait Until Event element, you can also get true early exits: add three paths, each an Email Link Click on one of the three specific links, all leading to End, with the 7-day timeout path leading to the resend. Check whether the element in your release shows "Add Event"/multiple paths; if it only allows one, use the fixed-wait version above. 

Tips: 

1. Give the three qualifying links distinct, stable URLs (e.g. unique UTM parameters) so they're easy to match in the decision and in reporting, and so the three non-qualifying links can't match accidentally. 

2. Because engagement data can arrive with some delay, a fixed 7-day wait followed by a decision is actually more reliable than racing a real-time event. 

3. Add a frequency/suppression rule or segment exclusion so contacts who unsubscribe or bounce also stop receiving the resends. 

References: 

Trailhead, Event-Triggered Flows in Marketing Cloud Next:

Community article on Wait Until Event in MC Next flows:

Assumption: I couldn't find official documentation confirming whether multiple event paths are supported in a single Wait Until Event element in your edition, or the exact field names for link-click criteria in the Decision element, so please verify those two points in your org; the overall recommendation (fixed wait + decision) doesn't depend on them.

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

Hi Khushal,

Looking at your screenshot, there is an immediate culprit visible right at the top bar:

1. The Flow Version is Currently Inactive

In your screenshot, the status pill next to the save date clearly shows Inactive, and the blue Activate button is present in the top-right corner.

• In Flow Builder, the Debug button works regardless of whether the flow is active, because it allows you to simulate execution on any saved draft version.

• However, a Data Cloud-Triggered Flow will never listen for or fire on incoming DMO events until it is explicitly Activated.

• Action: Click Activate in the top right, make sure the status pill turns green (Active), and then test again.

If it remains inactive or fails to trigger even after activating, check these three common Data Cloud-specific caveats:

2. Check the Start Element Entry Condition Requirement

In the start element, you have "1 Entry Condition" defined:

• When setting entry criteria with "A record is created or updated", check the evaluation setting: "Only when a record is updated to meet the condition requirements" vs. "Every time a record is updated and meets the condition requirements".

• In Data Cloud, change-data-capture evaluation for previous values can behave unexpectedly if incoming updates from ingestion streams batch or upsert without firing delta states. If possible, set it to evaluate every time or handle the strict filtering inside your decision elements instead.

3. Ingestion & DLO-to-DMO Mapping Cadence

• How is the consent record being updated upstream? If it enters via a Data Stream (e.g., Connector or Ingestion API), it writes to a Data Lake Object (DLO) first.

• The Data Cloud-Triggered Flow listens to the DMO (ssot__CommunicationSubscriptionConsent__dlm), not the DLO. Depending on the ingestion stream type (streaming vs. hourly/batch batch run), there can be a delay between the data entering Data Cloud and the DMO upsert actually publishing the change event that the flow subscribes to.

4. Data Space Mismatch

• Your start element is set to Data Space: default.

• Ensure the incoming consent updates are actually being ingested and resolved into the default Data Space and not routed into a custom Data Space (which would isolate the records from this trigger).

Summary: Hit the blue Activate button first—that is almost certainly why Debug works while real events are completely ignored!

Hii  

Khushal, 

    The reason LinkName is coming back blank is the root cause here — it's expected behavior, not a bug, when links aren't given an explicit identifier at authoring time.

Why $Event.ssot__LinkURL__c isn't reliable

That field returns Salesforce's rewritten/tracked redirect URL, not your original destination URL, so matching on it directly in a Decision element is fragile.

Recommended fix: set a unique alias on each button

1. In your email in the Marketing Cloud Next content builder, open each of the three buttons (Interested / Not Interested / Unsure).
2. In the button/link properties, set a distinct Link Name (alias) for each — e.g. Interested, NotInterested, Unsure.
3. Send a fresh test and re-check the Email Engagement DMO record in Data Explorer — LinkName should now be populated instead of blank.
4. In your flow, keep your Wait Until Event → Email Link Click element as is, then in the Decision element branch on the Link Name resource (ssot__LinkName__c) instead of the URL field. This gives you a clean, exact match for each of the three outcomes.

Alternative, if you can't set an alias

(e.g. dynamic/personalized links) 

Use the

Since your three buttons are static, setting the alias is the cleaner, more maintainable option — it's purpose-built for exactly this scenario and avoids any URL-parsing logic in your flow.