I am always happy to share interesting Salesforce Marketing Cloud use cases. So I wasn’t late to accept the invitation from Jyothsna Bitra to showcase orchestrating cross channel journeys with Wait Until API Event Activity. In case you missed the session, the recording just found it’s way the interwebs.
– Are you curious on how to connect Cloud Pages to JB API?
– Do you need to understand when using Wait Until API Event Activity is a good idea?
– Want to learn how to collect form data using the Wait Until API?
Then wait no longer, and check out the article below! I’m sharing a deeper look into orchestrating cross-channel journey experiences using the API wait step and Cloud Pages in Marketing Cloud. My recent session on this topic was part of the MC Learning Camp series, and it sparked some fantastic questions around both the technical setup and strategic applications of these tools. Here’s an enriched overview of the session to help you understand how these tools can elevate your journey-building capabilities in Marketing Cloud.
If you want to get all the details, you can watch the recording of this session here:
The Power of the API Wait Step: Why It’s Essential for Dynamic Journeys
The API wait step is a versatile yet often underutilized feature that enables journey flows to adapt based on real-time data or actions outside the journey. Typically, marketers rely on decision splits or engagement splits for branching flows, but the API wait step brings something new to the table: it allows journeys to pause at specific points until a predetermined external event occurs. It also has a built-in fallback path if the event doesn’t happen within the designated timeframe, giving you control over both paths of the journey.
For example, if a customer completes an online registration, an API event can trigger an initial confirmation email. At that point, the journey can wait for their action (such as a form submission or confirmation click) before advancing. This wait step can be set to expire if no action occurs, at which point the journey would automatically switch to a different path, perhaps sending a reminder email or stopping communication altogether if consent isn’t confirmed. This flexibility is incredibly valuable for personalized experiences and automated workflows.
Setting Up the API Wait Step: Key Components and Considerations
In the session, I guided attendees through the setup of the API wait step, breaking down the configuration essentials for an effective implementation. Here’s a summary of the key points:
- Entry Sources: Although I used an API event entry source for demonstration purposes, the API wait step works equally well with other entry sources like data extensions. This flexibility makes it adaptable across different journey types.
- Configuring Data Extensions: To manage data payloads effectively, I recommend creating separate data extensions for initial API events and wait events. This separation helps prevent conflicts — especially if your journey allows re-entries — and reduces the risk of primary key violations when handling multiple entries or updates to the same contact.
- Technical Setup of the API Call: The wait step requires an API call to trigger movement through the journey. Here, I demonstrated how to set up a secondary API endpoint with its own event definition key. Importantly, this API call uses the same endpoint as the entry event, which means that a single API structure can support both initial journey entry and wait step continuation. This streamlined approach simplifies the development process while maintaining flexibility for more complex, event-driven journeys.
- Timeout Configuration: As with any journey involving wait steps, the API wait step requires a maximum duration for waiting. If no external event triggers the next step within this timeframe, contacts proceed down an alternate path. This configuration ensures contacts aren’t left in limbo and that the journey flow remains smooth even in cases of non-response.
Practical Use Cases for API Wait Steps
During the session, I shared a few specific examples that show how API wait steps can be used in real-world scenarios:
- Double Opt-In Process: For companies requiring consent verification, an API wait step can streamline the double opt-in process. After a user registers on a website, an initial API event sends a confirmation email. When the user clicks a confirmation link, a secondary API call releases them from the wait step, allowing them to continue in the journey. If no response is received within the specified timeframe, the journey can follow a different path—such as sending a reminder email or stopping communication altogether.
- Booking Confirmations and Cancellations: Another example involves a booking system. Let’s say a user receives an email inviting them to choose from several hotel options. Once they select a hotel and submit their choice via Cloud Pages, an API call pushes them through the journey, triggering a confirmation email. If no action is taken after a certain time, the journey could automatically cancel the booking or prompt further action from the customer.
Ensuring Data Security: Key Management and Encryption
Data security is a top priority, and I’m glad we had a robust discussion on handling sensitive data in these workflows. Here are some best practices we covered:
- Subscriber Keys: Avoid using email addresses or other personally identifiable information (PII) as subscriber keys. Instead, consider using hashed subscriber keys or generating unique IDs that don’t reveal sensitive information.
- Data Encryption: I recommend using Marketing Cloud’s built-in encryption functions for additional security when passing subscriber data to external systems. Although decrypting data outside Marketing Cloud can be complex, integrating Key Management allows you to manage encryption keys securely, limiting access only to those with administrative rights.
- Securing API Calls: To enhance security in cross-channel journeys, you can use hashed keys for web-to-cloud integrations. This involves sending encrypted or hashed subscriber keys in URLs or API calls, which external systems can decrypt as needed. For journeys that interact with external applications, creating backend processes in systems like PHP to translate hashed subscriber keys ensures data remains secure.
Journey Data Management: Best Practices for API-Triggered Journeys
One key distinction I highlighted was how the API wait step interacts with journey data:
- Initial Data Snapshot: Journey data is set when a contact first enters the journey and doesn’t update based on subsequent API events. This means any data collected from the API wait step will not alter the initial journey data snapshot.
- Using Lookups for Additional Data: Since API wait events don’t update journey data, I recommend using data lookups to retrieve specific fields if they’re required for decision splits or messaging post-wait. For instance, in the booking confirmation example, if a customer selects a hotel from a list and submits their preferences, the journey can reference this data through a lookup in the data extension, ensuring the messaging is personalized without relying on journey data updates.
Audience Engagement and Interactive Q&A
The session included a vibrant Q&A segment, with participants sharing excellent questions and insights on various aspects of API wait steps. Key topics included securely passing subscriber keys in URLs, handling data extensions with multiple entries, and troubleshooting API configurations for journey entries. These discussions not only added depth to the session but also highlighted the broader security considerations when integrating Marketing Cloud with other systems.
Final Thoughts
The API wait step and Cloud Pages are powerful tools that allow journeys to respond to user actions in real-time, providing a truly adaptive experience. These features enable us to integrate Marketing Cloud with other systems seamlessly, creating customer journeys that are both dynamic and secure.
Thank you to everyone who attended the session and for your thoughtful questions. I look forward to seeing how you’ll implement these concepts in your own Marketing Cloud projects. And as always, feel free to reach out with questions or check the Trailblazer community for further discussions.