I'd like to move one of our lifecycle smart campaigns to be executable to speed the process a bit.
The way the program is currently set up is based on a person being created in the system (trigger). The flow then points to requested campaigns based on the persons interaction. Example, they score 100 points, go through the smart campaign to pass to sales. The trigger campaign is set up with wait steps at the moment to make sure they go through the individual requested campaigns, then we have a sync to SF step.
I created a new trigger campaign (not activated yet) for when a person is created and changed "request campaign" to "execute campaign," pointing to the same (live) smart campaigns. Will this work if the existing campaigns that are in the flow were not marked as executable? Or do I need to create all new smart campaigns for everything? Also, I'm still a little unclear what "Use Parent Campaign Token Content" means- can someone please explain this?
Solved! Go to Solution.
The execute campaign flow step is designed to work only with the executable campaigns - i.e., you would need to re-create the campaigns as executable campaign and then use them in the pilot campaign's execute campaign flow step. Also, existing campaigns cannot be converted to Executable campaigns, you would need to clone them (after removing any triggers, or illegal flow step(s) - wait and call webhook from the campaign)
Also, parent campaign will essentially be in a program / campaign folder and when you check mark the "Use Parent Campaign Token Context" the token context from the parent campaign will be passed to be referenced in the executable campaign's flow (which are essentially the child level campaigns executed by the parent level campaign) - i.e. in simple words your child level executable campaigns would be able to use the program / folder level token values that the parent campaign has access to. This POC doc does a good job of explaining the concept of passing the parent campaign token context to executable campaign. Additionally, the product documentation has also some good content with examples on how token inheritance in the executable campaign works, if you would like to refer.
The execute campaign flow step is designed to work only with the executable campaigns - i.e., you would need to re-create the campaigns as executable campaign and then use them in the pilot campaign's execute campaign flow step. Also, existing campaigns cannot be converted to Executable campaigns, you would need to clone them (after removing any triggers, or illegal flow step(s) - wait and call webhook from the campaign)
Also, parent campaign will essentially be in a program / campaign folder and when you check mark the "Use Parent Campaign Token Context" the token context from the parent campaign will be passed to be referenced in the executable campaign's flow (which are essentially the child level campaigns executed by the parent level campaign) - i.e. in simple words your child level executable campaigns would be able to use the program / folder level token values that the parent campaign has access to. This POC doc does a good job of explaining the concept of passing the parent campaign token context to executable campaign. Additionally, the product documentation has also some good content with examples on how token inheritance in the executable campaign works, if you would like to refer.
Thank you so much for this!
I'm going to recreate campaigns to be executable. I noticed that triggers are not available in executable campaigns- since we're sending them to executable campaigns based on criteria from the first campaign- can the smart list flow be empty here?
Yes, triggers are not allowed in the executable campaigns. You can choose to leave the exec campaign's smart list empty but that would let anybody sent by the parent campaign through the execute campaign flow step in the executable campaign's flow w/o any checks / filters, of course given that they qualify for the qualification rules set in the campaign's schedule tab (which is probably okay for your use-case given that you do apt checks before sending people to the executable campaign and there probably isn't any other parent level campaign from which you're gonna execute this child executable campaign). But I personally prefer adding at least some base line filters to my executable campaigns just as a secondary check to not let anyone flow through the campaign's flow who shouldn't ideally.
Thats really well explained, @Darshil_Shah1
@dtrosky
In Addition to Darshil’s note.
Thanks,
Avinash Jadhav