We all know how to talk about the key operational programs in a Marketo instance: Lifecycle Processing, Scoring, Data Management, etc. We know the function they serve and their importance.
Although we’re talking about the same types of programs, the approach to how these programs are architected varies from company to company. We’re not all speaking the same marketing automation language. It’s time to create terminology that all experts can use, develop philosophical frameworks for how Marketing Technology can scale, and lay the foundation for a framework to build scalable Marketo architecture.
How to talk about Marketo Architecture
At Etumos, we take a developer-mindset approach to Marketo architecture—we architect programs to be modular, human-readable, logical and as efficient as possible. How we build has necessitated how we talk about these types of Marketo smart campaigns, flow steps, and operational programs. Think snippets of reusable code, just within the Marketo UI. We refer to these snippets as ‘components’ that make the scalable programs within the Etumos Framework.
Defining these components gives our team of architects a language we can use to talk about how programs are structured, either when planning or when reviewing new builds. The components themselves give us a modular starting place when creating a new piece of Marketo architecture. What follows is a list of some of our most used components, their purpose, and how we often use them.
Before we dive in, there are many people with strong opinions about requested campaigns, and we’re among them. We’re in favor of request campaigns and have proven that they can actually speed up time-sensitive processes by preventing these campaigns from being deprioritized. You’ll see that our architecture relies on requested campaigns to connect the components that follow.
Program Modules
Not really a component, but a good place to provide some context. We refer to each of the core operational programs that tie into the Lifecycle Processing program as program modules. Each of these programs has an input (program trigger) and an output (executed flow, or requests of an additional program module). As examples, these are operational programs like Subscription Center, scoring programs and backup CRM sync programs that are requested modules. When these modules are called depends on the urgency of the processes they perform. Often, these program modules are requested from Lifecycle Processing shortly after lead creation (as seen in the image below).
Program Triggers
Program Triggers are the smart campaigns within an operational program module that trigger a lead to be processed by that program module. This can be a simple Request Campaign from Lifecycle Processing or another program module, or it could include a data value or Marketo activity trigger.
In all cases, the function is to trigger lead processing and the output or campaign flow is to request a campaign that contains logic for how the lead should be processed by the program module. This means requesting either a Campaign Router, Controller, or Daisy Chain (each described below).
In large architectures of operational programs, we separate Triggers into their own folder, and we know that all of the other smart campaigns are being originally started by the few campaigns in the Triggers folder. This gives us an easy place to bottleneck flows (e.g., have a single campaign with “flow through once” instead of every single downstream smart campaign, or have only three smart campaigns gated with “email address contains @etumos.com” when we’re testing).
In the above image, we can see the program trigger being used to trigger leads into the Traffic Director program module is dependent on a Subscription Center field data value being change.
Cross-System Indicator (CSI)
Cross-System Indicators (CSIs) are how we refer to fields that are used between Marketo and other integrated systems that serve to indicate when a process in another platform has been completed. CSIs are hugely important for incorporating into program triggers when it’s necessary to control race conditions, because they allow you to determine when a dependent process has finished, and prevent you from having to rely on fixed wait steps.
For example, a CSI that has been helpful is facilitating Lifecycle Processing between Marketo and SFDC.
- Once Lifecycle Processing has completed its updates, such as through data enrichment, it marks the CSI field as “001 Marketo Processing Complete.
- SFDC processing is triggered when the CSI field changes to “001 Marketo Processing Complete,” which then does separate and custom enrichment from product information. When that enrichment is completed on the SFDC side, the final step is to change that CSI field to “002 SFDC Processing Complete.”
- Marketo watches for this data value change and continues the rest of the Processing.
This gives us synchronous timing availability between systems and gets us off of (unreliable) wait steps.
CSIs can also be incorporated into webhook payloads. For more information about how you can take processing outside of Marketo, checkout how we use FlowBoost to do everything from complex process to simple cross-system checks.
Cascading Logic
Cascading Logic isn’t a new concept in Marketo. It’s at the heart of how Marketo segmentations are configured, and it’s how we build smart campaign routers to identify a single prioritized choice within a flow step. Cascading logic is the practice of evaluating an if statement, selecting those who qualify and moving on to the next logic statement within a flow step until all choices within a flow step have been evaluated. The outcome is that any given lead will only qualify for a single option, whether this is an add to list, email send, or a requested campaign. Cascading logic is used in Router Campaigns (shown below).
Router Campaigns (single selection)
Campaign routers are how we refer to campaigns that evaluate leads using cascading logic to route leads to a single downstream process. This type of campaign serves to ensure that leads only qualify for a single processing outcome and is an alternative to multiple triggered campaigns, each with mutually exclusive smart list logic (something that is difficult to maintain and scale over time). We like to colloquially refer to this as “tree logic,” since it’s a building block that takes a single stream and separates the stream into a few different “branches.”
In the above image, you can see how we use cascading logic within a campaign router to direct leads to the correct campaign for additional processing. In the example above, we’re routing new leads into the correct Lifecycle Processing stage, where additional processing will be completed as necessary.
Controller Campaigns (asynchronous)
Controller campaigns are how we refer to campaigns that request multiple downstream asynchronous processes using logic within multiple campaign flow steps. This type of campaign serves to consolidate all of the processes that are being initiated at one time and can be used when timing dependencies do not exist between the requested campaign processes. Consolidating campaigns makes it easier to interpret what processes are being initiated.
Take lead creation for example. When a lead is created there is a lot that needs to happen: scoring, sourcing, email verification, and Lifecycle stage sorting to name a few, and many of these processes can happen independently of one another. In the image below, we can see an example of a campaign switch being used to consolidate processes triggered off of lead create.
Switches (execution)
Switches are how we refer to the flow steps within campaigns that contain logic to determine whether a specific flow step will be requested—this gives us the ability to have optional flow steps based on smart list criteria. Within a controller campaign there can be multiple switches each evaluating logic for an independent downstream process.
Take subscription center for example. When a new opt-in lead is created, it can qualify for multiple subscriptions and there are no timing dependencies for when a lead is added to one subscription vs another. Each of the switches (individual flow steps) within the controller campaign can contain a different set of criteria for evaluating whether a lead qualifies for each subscription.
In the image above, we can see how smart lists are used within the flow step (switches) to allow leads to be evaluated against different criteria for each subscription.
Daisy Chains (synchronous)
Daisy chains are how we refer to smart campaigns that are linked via request campaign, for the purpose of executing a series of campaigns synchronously. Daisy chained campaigns are another useful solution for addressing race conditions. They allow us to ensure that one action has been completed before attempting to initiate a downstream process. Daisy chains can also be used to connect program modules.
Examples:
- managing time sensitive lead creation activities (enrichment before routing)
- requesting nurture after assigning subscription center settings
- linking demographic scoring campaigns to ensure an accurate final score
The list of time sensitive processes goes on.
In the image above, we can see how demographic scoring campaigns can be daisy chained together with campaign ‘110 – Revenue’ being requested first, performing it’s score assessment before requesting campaign ‘120 – Company Location’. Daisy chained campaigns allow each campaign to evaluate and assign score to ensure that all scoring has been completed before requesting any additional downstream processes. In this case, scoring must be completed before we can evaluate whether the lead is demographically qualified.
When you pair each of these components with best practice naming conventions and commented campaign descriptions, you end up with Marketo architecture that’s robust, scalable and easily interpreted by other Marketo specialists. This not only creates processing efficiencies within the program, but streamlines how your team tackles Marketo architecture.
