New Lead Processing Queues

Remember “PEMDAS” in school? That little trick to figuring out the right order of operations for solving algebra equations?

So if you had to solve an equation like 4 x (3 + 4), PEMDAS would tell you to solve the stuff in the parentheses first before multiplying so that you’d get the correct answer.

I find myself confronted with the same sort of “order of operations” conundrums in Marketo all the time. When a new lead is created, there are actions, like data value changes and program associations, that I want to ensure occur ahead of something else, such as a Salesforce sync. But these actions often exist in disparate areas, and there isn’t an obvious, direct way to control what happens first.

Or is there?

The Campaign is Requested/Request Campaign trigger & flowstep combination is a powerful way to allow control over the order of disparate triggers.

Take a new lead creation action, as an example. For us, there are several data steps we want to occur before anything gets synced to Salesforce. For instance, we want to ensure the new lead isn’t missing any key values, like lead source, status, etc. We also want to ensure their country name/state name match an approved list of values (aka we want “United States”, not “USA” or “‘Merica”).

The essence of this is a chain of triggered smart campaigns that all use the “Campaign is Requested” trigger, and their flowstep ends with a “request campaign” flowstep, requesting the next campaign in the series.

Here’s an example of how these chain together:

1. Step 1: Lead Created (this one just watches for new leads created in the system, and kicks of the chain of actions)
   1. Trigger: Lead Is Created
   2. Flowstep: Request Campaign: Step 2
2. Step 2: Clean up Lead Source & Type
   1. Trigger: Campaign is Requested
   2. Flowstep 1: If lead source is empty, populate with a default value
   3. Flowstep 2: if lead source is irregular, normalize it
   4. Flowstep 3: Request Campaign: Step 3
3. Step 3: Fix Geographic fields
   1. Trigger: Campaign is Requested
   2. Flowstep 1:
      1. Choice 1: if Country is US, USA, United States of America, America etc, change value to “United States”
      2. Choice 2: if Country is “England, Scotland, etc” change value to “United Kingdom”
   3. Flowstep 2: Request Campaign: Step 4
4. Step 4: Assign to a Nurture Program
   1. Trigger: Campaign is Requested
   2. Flowstep 1:
      1. Choice 1 If lead meets whatever criteria you use to assign to a nurture stream, add to engagement program
   3. Flowstep 2: Request Campaign – Continue until you reach the end of the chain

The examples I’ve described above are primarily data management & manipulation, but a new lead processing queue can also be handy for engagement program assignment, or calling external services and webhooks. For example, suppose you use a lead enrichment tool that works via a webhook. Include that step as part of your new lead processing queue, and you can ensure all new leads get enriched as they enter the database.

Completing the queue before a CRM sync

While the processing queue can be extremely handy on its own, some special considerations come into play if you’re trying to ensure the queue occurs before a sync to your CRM.  . First consider all the activities that could sync a lead to Salesforce. This includes any existing smart campaigns that use the “Sync to Salesforce” or any other Salesforce related flowstep, along with any programs that are tied to a Salesforce campaign (This last one is the one most people forget).

We’re heavy users of the program to campaign sync, so minding when the sync occurs relative to our processing queue is really important. We don’t want leads accidentally ending up in Salesforce before we get a chance to clean their data up. The way to prevent this is build in a wait step in front of any program status change steps. So if you have an event program with a smart campaign that updates a lead’s status to “Registered”, you need a wait step of a couple of minutes in front of the status change flowstep.

Unless you have a really long queue of complex actions, usually 2-3 minute wait steps is plenty. But if you really want to hone in on how long your queue takes to process, you can create timestamp fields for start and end times, and have the first campaign in your queue stamp leads on entry, and the final campaign stamp on completion. Then after you have a few weeks of data, export all the leads that ran through the system, and calculate the average time between start and end.

A few caveats

• I like to avoid excess use of trigger campaigns in Marketo where possible, as at scale, they can significantly degrade performance of the tool. In a way, this processing queue is beneficial in this regard, because you’re effectively consolidating many of your disparate trigger campaigns into a single, orderly list. However if you are a user with a database of significant size, you’ll want to thoroughly test out a processing queue such as the one above to confirm performance isn’t negatively impacted.
• A longer processing queue can get a bit bogged down with big list imports or other batch creation of leads. So don’t rely on it here, as these may cause a spike in processing time, and may cause a sync to occur before the queue gets done processing.
• Programs with a landing page and form in them will automatically assign a program status when a form is completed. It’s something Marketo does that you cannot disable, presumably as a safeguard if you were to build a program and forget to active your smart campaigns. This is super annoying. A way to get around this is by storing your landing pages in programs that are not tied to a Salesforce campaign, or by using the Add to Salesforce campaign actions instead of the program-campaign sync feature.

Once you get a basic processing queue up and running, it’s super easy to expand and modify it. It also makes hunting down critical lead creation activities a breeze, since they’re all chained together in a nice, ordered list.