An Executable Campaign, like other campaigns, contains a Smart List, Flow, and Schedule. Unlike other campaigns, you do not actually schedule or activate it. It can only be called by another campaign via the Execute Campaign flow step. The flow steps in the Executable Campaign are run in series with the parent campaign (unlike Request Campaign, which runs in parallel in a separate Trigger Campaign).
Executable Campaigns are always children of the (parent) campaign that calls them.
There many things you can do with an Executable Campaign. They are designed to facilitate common operational tasks, like lead routing, lifecycle management, and scoring (among others), and can be used to execute the same workflow from within Batch or Triggered Campaigns.
You can also use them when you need to run a separate flow, but you need to depend upon the results of that flow in subsequent flow step choices (i.e., if this, do that).
Execute Campaign is an improvement upon Request Campaign, as it can run in-series or in parallel, whereas the latter only runs in parallel.
Wait Steps and Webhooks will never be compatible with Executable Campaigns. For those, you’ll need to use Request Campaign instead.
Right-click on your desired program and select New Smart Campaign.
Give it a name, select the Executable checkbox, and click Create.
Define the Smart List and Flow, like any other Smart Campaign.
You can also clone an existing Smart Campaign. If you clone an existing Executable Campaign, you will still have to select the Executable checkbox after naming it.
You can’t clone a campaign that contains triggers.
When set to true, the following token contexts will be sent into the child campaign (the one being executed):
API Interaction
When using Schedule or Request Campaign in the API, both let you pass values for My Tokens, which overrides the values set for those tokens in the campaign you’re calling. If that Campaign then executes another campaign and sets “Use Parent Context to True,” it will use the values passed through the API, rather than the values which are set in the application.
Never leave your smart lists for Executable Campaigns invalid, otherwise no one will qualify for it. Best practice is to create separate smart list assets, define them completely, and make sure they’re valid. Then, use the “Member of Smart List” filter in the Executable Campaign so you can swap your smart list definition.
Below is a visual example of Token Inheritance in one Executable Campaign and two parent campaigns: one with token context set to True, the other to False.
Child campaign with a tokenized Change Score.
The child campaign’s My Tokens.
Example One - True
In the Execute Campaign flow step of the first parent campaign, the “Use Parent Campaign Token Context” is set to True.
The parent campaign’s My Tokens.
The results: score changed by +10.
Example Two: False
In the Execute Campaign filter of the second parent campaign, the “Use Parent Campaign Token Context” is set to False.
The parent campaign’s My Tokens.
The results: score unchanged, because the child campaign’s score value, +0, was used.