Executable campaigns are a powerful new feature designed to allow you to make your campaign logic modular, reusable and maintainable. However, staying within the limit of three nested executables can be difficult when your campaign trees get complicated. This article describes a simple method of classifying your executables into three categories to help you stay within the nesting limits while also remaining productive.
Three Categories for Executable Campaigns
This classification system has three categories with simple definitions:
Tier 1: These campaigns may not be executed by other executable campaigns
Tier 2: These campaigns may not execute other Tier 2 campaigns
Tier 3: These campaigns may not execute any other campaigns
By classifying your campaigns in this way, and abiding by their restrictions, you can avoid bumping up against the nesting limit.
Now we have a way to avoid the nesting limit, but how should you map your existing campaign logic and lifecycles into these categories? Let’s look at Tier 3 first, as it is the foundation of this model
Tier 3 – Task/Unit - May Not Execute Any Other Campaigns
Tier 3 cannot execute any other campaigns, and this is where individual tasks should be implemented. Your organization can define what a task is in this context, but I think that it is useful to borrow the definition of unit from software development: A unit is the smallest testable part of any software. In the context of Marketo, a unit is the smallest testable part of any campaign.
Let’s look at a common example for lead lifecycles: Taking a country input and outputting a country code to a different field.
The above is an abbreviated example using flow-step choices to match the value of Country to a particular country code. Supposing we wrote a test for this, we would expect a lead who enters the flow with an empty value of “United States of America” to receive a Country Code value of “US”.
This or similar steps could be a unit for your business, but you do not need to limit your units to single steps. Your Tier 3 task campaigns should tend to be short sequences of work which are used in multiple contexts
Tier 2 – Orchestration – May Not Execute Other Tier 2 Campaigns
Tier 2 (as well as Tier 1) are more flexible than Tier 3 campaigns as they can execute other campaigns themselves. These executables can be used to string sequences of other campaigns together alongside standalone flow steps. An example would be a Standard Data Enrichment campaign. Where normalizing a country code is a unit or task, this is a sequence of one or more data enrichment tasks that can be maintained and modified separately from the logic of the individual tasks themselves
Tier 1 – Last-Mile – May Not Be Executed by Other Executable Campaigns
You may find that your business does not need to use Tier 1 campaigns, and that you can satisfy your organizational needs with just Tier 2 & 3 campaigns. However, Tier 1 campaigns allow an additional layer of flexibility for you to manage your campaigns. Typically, one of these campaigns will call a mix of individual flow steps, and Tier 2 & 3 campaigns to assemble a flow for a typical lifecycle event, like a Standard New Lead Flow. These typically include data enrichment, normalization, scoring, and routing flows, which can be created as tier 2 or 3 campaigns.
[FAQ attached below this article]
On August 31, 2020, Marketo Engage will implement a new retention policy specifically for Sent & Delivered Email activities. Under this policy, data for these two activity types will be stored for a rolling 90-day period from the activity date for use in Smart Lists. This is a change from the current default retention period of 25 months, and from the current Extended Data Retention subscription option period of 37 months.
Upon the policy taking effect, data older than 90 days for these two activities will be deleted and no longer available for export. Any Smart List with the “Was Sent Email” and “Was Delivered Email” filters (including NOT Was Sent and NOT Was Delivered) should be updated to ensure the maximum lookback date is 90 days. If the lookback date is greater than 90 days, the Smart List will continue to function, but only activities that are 90 days old or less will qualify.
In 2020, we are improving critical parts of the underlying Marketo Engage infrastructure, including Batch campaign processing, similar to the Trigger campaign improvements made in 2019. This new infrastructure, in combination with the new retention policy, is expected to result in shorter lead time with large email sends and faster segmentation processing to deliver significantly faster processing to our customers. Note, the revised retention policy is one, among several, aspects that come together to deliver this improved performance, but broadly speaking reduced retention helps with faster database look ups and search across the run-time infrastructure.
What's NOT Changing?
Aggregated data – including Reports, Dashboards, and Analytics – will not be affected by this change (unless they reference a Smart List with these activities). The new policy will not affect any activity type other than Sent and Delivered (for example, Was Opened activity data is not affected). Further, this change does NOT affect Engagement Program casts.
What Customer Actions Are Needed?
First, you'll want revisit where and how you're using these two activity types. Audit your Smart Lists and ensure the date ranges for these two activity types are less than 90 days - if you must use a date greater than 90 days, we suggest running a process to export to an external system. You will need to create this before the new retention policy takes effect on August 31, 2020. Information on how to export activities using APIs can be found on our Developers Documentation website.
We appreciate you understanding as we move toward an enhanced Marketo Engage experience for all customers. Please download and review the FAQ attached below for further suggestions, workarounds and additional information.
In January 2021, we released the Submit Form API endpoint to give Marketo Engage integrators the ability to submit to Marketo Forms through a supported and authenticated REST endpoint. Thanks to customer feedback we were able to identify a lack of parity for critical functionality such as correct handling of duplicate records and support for Program Member Custom Fields. These issues blocked some integrators from successfully onboarding onto the Submit Form API endpoint.
In our August release, we have enhanced the Submit Form endpoint to handle duplicate records the same way as Marketo forms. When there are duplicate records that match an email address submitted to the form, the endpoint will update the record with the most recent Last Modified Date.
In our October 22, 2021 release, we plan to release support for Program Member Custom Fields for the Submit Form REST API endpoint. We understand that integrators will need time to update and test these new changes before they can fully onboard onto the Submit Form endpoint. To allow additional time for migration, we are delaying blocking programmatic POSTs to the /save2 endpoint to our January 21, 2022 release. This will be the final extension.
Programmatic submissions to our form endpoints remain unsupported despite this delay. Please work to update integrations submitting via this method to one that is supported: Marketo Engage forms on Landing Pages or using the embed code, our Forms2.js API, or the Submit Form API endpoint.
Previous announcement: https://nation.marketo.com/t5/product-documents/updated-april-2021-upcoming-changes-to-the-marketo-engage-form/ta-p/306631