Photo by Campaign Creators on Unsplash

Salesforce Marketing Cloud Engagement (MCE) is strong right out of the box. Thousands of businesses make great use of it without writing any code. But if you need more — and especially if you’re comfortable drawing outside the lines — the power you can harness with MCE is a thing to behold.

Background

Agribusiness, omni-channel communications, and lightning web components don’t have much in common, but recently I learned they share one thing in common: I knew little about them. And while Agribusiness remains mostly a mystery (at least to me), I’ve come to appreciate how MCE’s cross-cloud Distributed Marketing feature can be extended to supercharge omni-channel communications.

I was working to help a business migrate from its home-grown communications platform to MCE — without disrupting familiar processes (for internal users) or messaging experience (for external customers). One of the strongest capabilities of the existing system was the ability to send to messages to three separate channels — email, SMS, and push — all at once.

MCE does this well, but I faced an interesting challenge: creating a solution that allowed the sender to enter content once, using Distributed Marketing, and then preview all three channels. Distributed Marketing is strong — but not that strong.

Then lightning struck. Our team came up with a brilliant idea. What if we could use a “display” email template as the first step in the journey. This would allow us to:

• show three communication channels in a single view,
• use an exclusion script to avoid the template from ever sending, and
• take the message content a user entered and display the preview and surface that content into customer-facing messages for each channel.

This would result in a journey that followed this flow:

An example journey flow using the display template concept.

While brilliant, our idea faced two major challenges:

1. How would we create a familiar, intuitive, user experience?
2. How would content flow from preview to live message?

Let’s delve into each.

Challenge #1: Build a familiar experience

The small army of MCE end-users wouldn’t take kindly to a workflow that felt half-baked or unfriendly. We wanted them to interact with previews that felt just like what their customers would see in their inboxes and on their devices. We knew the solution needed to be visual — to look and feel like an email, an SMS, and a push notification. Our end users needed to understand the customer experience, something a plain-text “rendering” of each message would not provide.

Starting with SMS, I grabbed the code from an SMS preview and created my own version of it in the HTML code of the display template. This allowed any SMS preview to appear like it would in MCE directly:

Custom SMS preview created using the same styling of a standard Mobile Connect message preview

Using this code:

HTML used to create a custom SMS preview

Next, I passed content from the email to the SMS and push messages, so that MCE users could enter content one time and preview it in three channels. To do this, we lifted the hood on the Distributed Marketing blocks. When a Distributed Marketing block is included in an email, MCE sets a few variables that help the system “know” which blocks to place in the email. Those variables include:

• Salesforce Org Id
• Journey Id
• Campaign Member ID

The values are fed to a personalization data extension for each Distributed Marketing send. The data extension houses the personalized content input in core-Salesforce. Content then flows into a variable called freeTextMsg.

Leveraging these existing pipes, we made a couple tweaks to the code and then applied them directly to our display templates. Instead of allowing Distributed Marketing to determine the email send, I passed email ID directly to the display template and voila! The preview retrieved the content for each message channel in one view.

The result looked like this:

An example of a finished display template showing a message across all three channels

Challenge #2: From preview to production

Now that we had a familiar, user-friendly interface for our end users, we turned our sights to the next challenge. Using the same logic — that relying on email ID to populate content in the SMS and push — we decided to extend it to actual, customer-facing sending activities. The result was a Distributed Marketing journey that could send to three channels with content sourced from a single place.

Bonus challenge: Push without the SDK

As consultants, we meet the client wherever they’re at. Sometimes we get lucky, and the client manifests a crew of in-house developers to hatch the building blocks we need for our MCE work. Most of the time, we stretch the platform (and ourselves) to make do with what we’ve got. This business was hamstrung by an aggressive timeline that left no space for them to integrate the MobilePush software development kit (SDK) into their existing mobile app. So, no push notifications? Not so fast….

In the organization’s home-grown system, push notifications were distributed through Google’s Firebase platform. They asked, could we “simply” use MCE to make API calls to Firebase in lieu of the SDK? Challenge accepted.

For authentication, the existing system used a java codebase to obtain access tokens for each message being sent using custom functionality which could only exist in the current platform. First, I tried using server-side JavaScript (SSJS) — this didn’t — it required some custom packages for the Firebase auth flow. So, I tried leveraging Python. Python successfully create access tokens and sent push notifications, but couldn’t run in MCE or core-Salesforce.

Then, I discovered Apex. We created a custom class that could run the Firebase OAuth process and successfully retrieve the token needed to make the notification calls. I tweaked the Apex class to not just retrieve the token, but once retrieved, pass it to an MCE data extension. From there, the class ran every 15 minutes, in line with a token’s lifespan.

All the messages would be sent from Journey Builder and required and on-demand API call to trigger the notification through Firebase. Without an SDK you can’t send push notifications natively so different pipes were needed. Enter another type of native notification: SMS.

With some tidy SSJS, embedded in an SMS activity, we fired an API call to send a push notification to a user’s device. By including a blank SMS body, the SMS itself was never actually sent; it served only as a mechanism to trigger the API call at the right moment. The process was as follows:

1. Retrieve Firebase token from the data extension.
2. Retrieve a user’s device ID — required in the Firebase payload — from core-Salesforce.
3. If a valid device ID is found, use the Firebase token, build the push message, and deploy it

Sample SSJS for firing an API call to Firebase.

This worked, but there are drawbacks. The push notification will not send if

• a contact is not opted-in to the SMS channel, or
• a contact’s record does not have a mobile phone number.

While this approach is more of a bridge (until the mobile SDK could be properly integrated into the mobile app) than a long-term solution, the near-term goal of simultaneous, cross-channel communications was successfully achieved.

Conclusion

It’s no accident that a feature-rich, easy-to-use platform like MCE is the market leader. Perennially stretched IT and Marketing teams have enough to worry about and gravitate to marketing technologies that (can) largely run themselves. But, if you’re painted into a corner or your requirements seem to mandate a magic wand, roll up your sleeves and get creative — it works.