Marketo’s Executable Campaigns (Explanation & Examples)

In Q1 of this year, Adobe released a handful of new features and improvements to Marketo…the standout/fan favorite of the release was Marketo’s new executable campaigns functionality. TL;DR: What I’m Pumped About: Program Token Inheritance Synchronous Processing What I’m Bummed About: Inability to nest executable campaigns (Adobe says this will be released in the future...

In Q1 of this year, Adobe released a handful of new features and improvements to Marketo…the standout/fan favorite of the release was Marketo’s new executable campaigns functionality.

TL;DR:

What I’m Pumped About:

  1. Program Token Inheritance
  2. Synchronous Processing

What I’m Bummed About:

  1. Inability to nest executable campaigns (Adobe says this will be released in the future though!!)
  2. Incompatible with webhooks (which makes sense I guess but still ๐Ÿ˜ฉ)

What are Executable Campaigns?

Executable campaigns are similar to Marketo’s requestable (is that a word? ๐Ÿค”) campaigns and are a way to tie together multiple smart campaigns. Both are very efficient in helping decrease race conditions and centralizing repeatable operational smart campaigns that can be called from multiple places in your instance.

How are Executable & Requestable Campaigns Different?

The main difference between the two is how Marketo processes them. Executable campaigns are processed synchronously whereas requestable campaigns are processed asynchronously. If you’re unfamiliar with those two terms (like I was ๐Ÿ˜…) here’s what Google told me. I’ve also created some visuals that will better explain the difference in how they are processed:

Requestable Campaign Processing:

As you can see below, the parent campaign consists of 4 flow steps, the 3rd being the request campaign that calls the child campaign. When a lead flows through the parent campaign, it flows in order of step 1, then 2, then 3 (which calls the child campaign flow step 1), then step 4 in the parent campaign. Marketo will begin processing flow step 1 in the child campaign, and also move to step 4 in the parent campaign without allowing all flow steps in the child campaign to finish processing.

No alt text provided for this image

Executable Campaign Processing:

Below we see the same parent and child campaign as the requestable campaign above, but with an execute campaign flow step (step 3) in the parent campaign. As you can see with the arrows, the parent campaign calls the child campaign (same as above) BUT the parent campaign will wait until the all flow steps in the child campaign are finished processing before moving on to the next step (step 4) in the parent campaign ๐Ÿคฏ

No alt text provided for this image

Why this is freakin’ awesome:

Okay, so this may not seem like a huge difference at first, but it gives us Marketo nerds an additional layer of control when it comes to automation. Meaning, it will help cut out on race conditions in our instances and keep things more orderly.

Additional awesomeness

Aside from the synchronous vs asynchronous differences, executable campaigns also allow for the inheritance of program level tokens from the parent campaign to the child campaign, which is completely unique to executable campaigns and previously wasn’t possible without them. When calling an executable campaign (from the parent campaign) it will give you the option of selecting to pass along my tokens from the parent campaign’s program that will be accessible in your executable campaign.

This is probably my favorite aspect of executable campaigns because it allows for program level tokens to be accessible via a centralized executable campaign that can be called by smart campaigns across your instance.

No alt text provided for this image

Examples

  1. More Efficient New Lead Processing:

Given the synchronous processing that comes with executable campaigns, they can be super effective for new lead processing (all the operational stuff that happens when a new lead is created). Instead of daisy chaining a bunch of smart campaigns together using requestable campaigns or by adding leads to an operational list to signal that one part of new lead processing is completed and the next may start (or whatever other creative way you are controlling the order of operations so a lead isn’t sync’d to SFDC before being enriched or sorted into a lifecycle stage before being scored), executable campaigns can streamline new lead processing and make it much easier to manage and scale. Simply “call” or execute each smart campaign in the correct order, and because of the synchronous processing of executable campaigns, new leads will always be processed in the correct order ๐Ÿ˜Ž

No alt text provided for this image

2. Centralized Interesting Moments (using token inheritance)

Okay-this is probably my favorite use case. Like most of you, interesting moments have been difficult to manage. You can either keep them at the program level and use program tokens to make them super custom (but harder to manage and make changes in the future cause you have like 50+ flow steps each in their own program if you want to make changes) The other option is creating centralized interesting moment smart campaigns using smart campaign trigger tokens (easier to manage and make changes to because there’s only one change BUT the trigger tokens kinda stink and aren’t super custom)

BOOM! IN COMES EXECUTABLE CAMPAIGNS!!!

Now you can have your cake and eat it too ๐Ÿฐ By using a single executable interesting moment campaign that inherits program tokens from each program across your instance you can have more specific interesting moments for your sales team that are also easy to make manage as a Marketo admin.

Content download smart campaign that calls a centralized executable interesting moment campaign and passes program level tokens:

No alt text provided for this image

Program level tokens:

No alt text provided for this image

Single executable interesting moment campaign (being called by each content download program):

No alt text provided for this image

End result in MSI in SFDC:

No alt text provided for this image

3. Centralized Slack User ID Campaign

One of the main uses cases for executable campaigns is anytime you have a smart campaign that is taking action on a lead, and one of the flow steps is dependent on some other field that needs to be populated PRIOR to that flow step processing.

One example I stumbled upon involves sending slack notifications to our sales team from Marketo via a webhook (the flow step that is dependent on a data value). We have a couple different slack notifications that go to our sales reps so there are multiple smart campaigns calling the webhook. BUT in order to @ mention a user in slack, you need the users specific Slack ID (the dependent field)

So instead of populating a lead’s “Sales Owner Slack ID” field in every single smart campaign sending notifications to Slack, I just created one using an executable campaign that I can call from anywhere in our Marketo instance.

Sound confusing? I’ll show you below๐Ÿ‘‡๐Ÿป

Here’s my “Slack ID Standardizer” executable campaign that is called by each smart campaign sending Slack notifications:

No alt text provided for this image

Because of the power of executable campaigns, I only have to create one central “Slack ID Standardizer” campaign that I can call from each of my smart campaigns sending slack notifications (saves me a lot of work)

Here’s an example from one of many smart campaigns that calls the Slack webhook for lead notifications (flow step 1 calls the “Slack ID Standardizer” executable campaign above):

No alt text provided for this image

In this example, flow step 2 is dependent on the “Sales Owner Slack ID” field being populated (if Marketo called the webhook for a lead that didn’t have a “Sales Owner Slack ID”, the sales rep wouldn’t get a notification). So here we use an executable campaign (because it’s processed synchronously) which ensures every single lead will have a “Sales Owner Slack ID” prior to the webhook being called. If we used a “Request Campaign” flow step here, the webhook could be called before the “Slack ID Standardizer” central campaign could populate the lead’s “Sales Owner Slack ID” field, because of the asynchronous processing.

Pretty cool stuff, huh? And the best part is, nestable (is that a word? ๐Ÿค”) executable campaigns seem to being coming soon from Adobe. Anyways, if you made it all the way down here, wow! Thanks for reading, hope ya learned something ๐Ÿค“

Post a comment