In the May 2021 Adobe Marketo Engage product release, a new feature called Executable Campaigns was released. This feature is similar to the request campaign/campaign is requested feature in that you must have a parent (requestor campaign) and child (requested campaign), however the main difference is in an executable campaign, the requested campaign must finish before the next flow step runs. This is a huge improvement to the campaign is requested feature because you will now be able to control and wait for certain actions to take place. Additionally, you’re also able to pass tokens from the parent campaign into the executable campaign. This feature is extremely helpful for scoring programs or updating data based on a triggered action.
In this blog, we'll demonstrate how to leverage request campaign, campaign is requested, and executable campaign for setting up a new lead processing program. Along the way, we'll highlight key benefits, differences, and limitations for each of these methods.
When a new lead is created in Adobe Marketo Engage, sometimes you need data to be populated by smart campaigns in a specific order to process leads, but you don’t want leads to sync to SFDC before it is ready. In the scenario below, we’ll walk through a common flow for new leads entering a database. This example assumes you have a program in Adobe Marketo Engage that standardizes data (an example would be updating common misspellings of the country to the correct value), data enrichment, lead scoring, and a lead lifecycle.
In this scenario, there is one traffic manager smart campaign where each of the requested campaigns are triggered right away. This traditional way of daisy-chaining campaigns is how most users force leads to go down a certain path in a specific order. While this will work most times, there are a couple of issues that you can experience, the largest being timing. Looking at the example below, we have 3 campaigns that I would like to have run in order:
In this example, the second and third steps are reliant on data from the prior steps to be populated. So, if there is a smart campaign backlog or maybe even a second or two delay, there’sa risk that a lead may go through a future campaign before finishing the prior campaign. While you can try to add wait steps into the flow, you will always have a potential risk of campaigns running out of order.
In this scenario, we eliminate the timing issues from the above example by requesting the next campaign as the last flow step in the campaign. This allows you to call the next campaign at the end of the flow once the previous steps have been completed, however, one major drawback is the lack of a centralized traffic manager. This example allows you to force the completion of the previous steps, before moving to the next one, however, if changes need to be made or issues arise, it’s much more difficult to troubleshoot issues outside of a single traffic manager.
With executable campaigns, you now have the ability to force a lead to finish a process before continuing onto the next without the need for wait steps or a decentralized program. Using the same example as above, with executable campaigns you now have the ability to force a lead to complete the data standardization campaign first before requesting the lead scoring and lead lifecycle campaigns. This provides you the ability to wait until all processes are completed before syncing to SFDC. The largest benefit of using executable campaigns is the ability to force a flow to finish, ensuring the data has been successfully updated. This provides you the benefit of keeping one master traffic manager campaign with the execute campaign where you can easily troubleshoot, plus a clean activity log on the lead where you can easily trace back any issues directly to a campaign. Additionally, since tokens can be sent from the parent campaign, you will have the ability to pass token information (like trigger.name or my.program name as an example) into the executable campaign to then use in change data flows.
When creating a new executable campaign, you will follow the same steps as creating a new smart campaign. The only difference is at the bottom of the “New Smart Campaign” pop-up, you will see an “Executable” checkbox. Once checked and created, your smart campaign is now an executable campaign. All executable campaigns are automatically activated
When cloning a smart campaign and making it an executable campaign, you can clone an existing smart campaign (doesn’t have to be an executable campaign) and make it an executable campaign by checking the “Executable” checkbox on the “New Smart Campaign” pop-up. This will create a new executable campaign!
NOTE: You cannot clone a campaign that has triggers into an executable campaign as this will fail. You will either need to remove the trigger prior to cloning or create a new campaign from scratch. Additionally, if the smart campaign you’re cloning has a “call webhook” flow step, the clone will also fail as webhooks are not supported in this feature.
When troubleshooting or investigating how the campaign ran, you will now be able to see whether or not a lead that had an executable campaign requested successfully ran through it or not. In the activity detail on the lead (double click from lead details), you will see a “Qualified” row and a true/false option. If the lead requested an executable campaign but there were additional filters in the executable campaign smart list that the lead did not qualify for, the “Qualified” value will be false and the lead will continue to the next flow step in the executing campaign.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.