Skip navigation
All Places > Marketo Whisperer: Implementation Tips > 2015 > September

This post originally appears on the Marketo Developers Blog

When your organization has many different platforms for hosting web content and customer data it becomes fairly common to need parallel submissions from a form so that the resulting data can be gathered in separate platforms. There are several strategies to do this, but the best one is often the simplest: Using the Forms 2 API to submit a hidden Marketo form. This will work with any new Marketo Form, but ideally you should create an empty form for this, which has no fields:

Empty Form

This will ensure that the form doesn’t load any more data than necessary, since we don’t need to render anything. Now just grab the embed code from your form and add it to the body of your desired page, making a small modification. You embed code includes a form element like this:

<form id="mktoForm_1068"></form>

You’ll want to add ‘style=”display:none”‘ to the element so it is not visible, like this:

<form id="mktoForm_1068" style="display:none"></form>

Once the form is embedded and hidden, the code to submit the form is really quite simple:

var myForm = MktoForms2.allForms()[0]; 
     //These are the values which will be submitted to Marketo
     "LastName":"Doe" });

Forms submitted this way will behave exactly like if the lead had filled out and submitted a visible form. Triggering the submission will vary between implementations since each one will have a different action to prompt it, but you can make it occur on basically any action. The important part is setting your fields and values correctly. Be sure to use the SOAP API name of your fields which you can find with Export Field Names to esnure correct submission of values.

Some of you may have noticed that you cannot currently use custom objects in segmentations. I have been lobbying for this feature for a while, but until it's available, never fear - another patented Kristen workaround is coming your way.


Why would you want to do this? Some examples of the use cases I've heard of:

  • Sending people different emails based off the product they've ordered, which is stored in an order object
  • Grouping people based on their brand preferences, which are also stored in a 1:N fashion since there are many brands


So what's my trick? Instead of using the custom objects in the segmentation, I use static lists and I create smart campaigns to add and remove people from the static lists based on the custom objects. Basically, the static lists become a middleman that allow me to use custom object data to define my segmentations.


Let's consider the case where I want to vary a welcome email's content based off the product, which is stored on a Sales Order custom object in Salesforce. The name of the product is stored in the Product Code Name field. First, create one static list for each product (Yes, I've deleted the product names to protect the innocent, I didn't magically name all my lists the same!):

Then create a smart campaign to listen for a new sales order that comes in with that particular product type. When you are using Dynamics, you can add this constraint directly to the custom entity trigger so you know that the constraint applies to that exact custom entity. When you're using Salesforce, you can't do this, so you need to combine the trigger with a filter that contains the constraint. In this case, we combined the Sales Order trigger with a filter for the Sales Order where we're further limiting the sales order by product and also by date (in this case, the date of shipment, but you could also use created date). This gives us a very high probability that this person is going to get added to the list based on that specific custom object having that specific product. (Again, not a concern with Dynamics!)


In the flow of this smart campaign, add the person to the relevant static list that you created earlier.


Then, create a segmentation that has one segment for each product. In the smart list for this particular segmentation, we opted to include people who were on one product's list but not on any of the others. (We decided that if you were on the list for two products, you should get a generic email.)

Once you have all your segments defined, approve the segmentation and use to make your email dynamic as desired.


Really Important Things to Consider

It's important to remember when you are doing this that you need to take into account a few things that are not considerations when you build segmentations off company or lead fields:

  • The segmentation will not update automatically when the custom object changes. Because the segmentation is actually built off a static list, you need to set up campaigns that will add and remove people from these lists if you want them to move from segment to segment. Only when that happens will your segmentation be updated. This does mean there will be a slightly longer delay for updates to the segmentation (and it may not always be 100% accurate), particularly if you are running these as batch campaigns.
  • Since people often have more than one custom object associated to them, you will run into issues where people qualify for more than one segment more often than you do when using lead/company filters. Remember the way we handle this by default is by the order of the segment. The lead will always end up in the segment they qualify for first, so order is super important. I recommend that when you are building segmentations off custom objects indirectly like this, that you strongly consider more robust exclusion criteria in your segments' smart lists so that you have more granular control over how that happens.
  • This is not a solution I'd recommend using all the time for really large volumes of data. It does add a bit of a performance burden on the instance in those cases, so use judiciously.

Did you ever wish you could easily compare email performance across your static lists?  I thought you might, so here’s a way to make your dream a reality...


1) First you’ll need to create a new segmentation.  Name is something like Static List Report.


2) Here’s your chance to name your lists the way you’d like to see them show up in the report. In my example I simply used the same name as the static lists found in the Group Lists in the Lead Database.

3) For each segment, create a Smart List and choose the static lists you want included in your report.


4) In Analytics, click on the Email Performance Report and clone the report (this is a best practice – always save the default report and customize it to meet your reporting needs. Remember to save your report to Group reports if you want to make it available to other users).


5) Pull over the Group by Segmentations filter and select your segmentation.


6) Set the Smart List filters Member of List and choose your static lists. Pull over the Was Delivered Email filter and choose Email: is any.  Also remember to choose the Sent Date you wish to report on.

7) View your report


Happy reporting!

I just got off the phone with a client who is just about to hit the “sync” button. It has taken us a lot of time to get to this stage, but it was time well spent… let me explain.


The vast majority of the migrations to Marketo that I have performed (and there have been a lot), have made the decision to migrate somewhat inside of a marketing bubble. Meaning nobody spoke to Tom, the Salesforce Admin, about what the implications might be for him, or more importantly, his data. Now admittedly, that is because Tom, the Salesforce Admin, is a bit surly, and fiercely protective of his SFDC data. You can’t win with that guy.  Needless to say, that means when I call Tom and start talking about the Marketo integration, I can feel him sending white shards of hate through my heart center before we even get through the introductions.


I totally empathize with Tom; he is kind of like the dragon protecting the gold in the cave (and I am pretty sure Tom LOVES The Lord of the Rings movies, and kind of likes that analogy anyway).  SFDC data is VERY valuable, and his job is to insure its integrity. The data that he is charged with is the lifeblood of your sales organization.


Invariably, what puts any SFDC admin at ease is when you present them with your migration plan. Mostly because, when you show them this plan - and I mean like a real document - It lets them know that you understand that the struggle is real; you value their role, and take them seriously. This is, of course, emphasized by the fact that your plan will include them in very real ways. 


Below are some tips to help insure your SFDC sync goes smoothly, and with any luck after the sync, Tom will invite you to his next Lord of the Rings party.


  • Use a sandbox! Even if it might cost you a little extra money, use it! Your SFDC admin will appreciate that you are taking your time and not trying to rush through this integration.  The sandbox will allow you to test and make sure that the sync is working as expected.
  • Use a data dictionary. This is a spreadsheet that you will use to document all of your fields both in SFDC and in Marketo. This will not only document mappings, but it will also document what permissions that Marketo will have on each field. If you are using Marketo Professional Services, your consultant can provide you with a blank dictionary to use, but if you are going it alone, this document is easy enough to create on your own.  Just make sure that you document the friendly names, API names, permissions, and mappings.
  • Understand the vernacular. Remember that in Marketo, Leads and Contacts are both called “leads”. This can become infuriatingly confusing for an SFDC admin. Circumvent this by using the correct vernacular when appropriate, and showing them how they can tell the difference in Marketo. (refer to the SFDC Type field)
  • Have a plan in place for duplicates. Duplicates can be a costly issue in any sales organization. Occasionally, duplicates are purposeful… but usually, they are the bane of Tom’s existence. Put Tom at ease by explaining how Marketo de-dupes, so that he knows that Marketo won’t further add to his duplication nightmare. Then further explain how you can set up Marketo to send an alert when a potential duplicate is created.
  • Custom objects, person accounts, etc. – Plan how you want Marketo to interact with these items, and understand the limitations that Marketo has with dealing with these items. Document all of these on their own tab in your data dictionary.
  • Restrict Marketo’s permissions to only what it absolutely needs.  If there is no reason for Marketo to be able to overwrite something, block that access. If you don’t want Marketo to be able to delete a record, block that from happening. Most importantly, involve Tom in this discussion.
  • Make your SFDC Admin an authorized support contact. This will put them at ease, knowing that they can go directly to support to solve a sync issue.
  • There will INVARIABLY be sync issues. The most common sync issues happen when the Marketo sync can’t access certain records. That’s ok, just send the error to your SFDC admin, they will investigate, and will see that there is likely a section of leads that were inadvertently blocked from the sync. He’ll fix it, and those leads will be updated on the next sync cycle. As frustrating as these sync errors are for you, they will actually put your SFDC Admin at ease, because that means that the sync is working as it is supposed to… only syncing EXACTLY what they tell it to.
  • Lastly, when the sync to sandbox is completed, TEST EVERYTHING, and document your test scripts. When your SFDC admin has approved the tests, ask if they are comfortable repeating the process in production (I go so far as to include a column in my testing document for the SFDC Admin to initial that they have reviewed the test). This is a huge step for them, and you want them to be very comfortable, so involve them in the process.


These are some very basic tips, but they will help you formulate an internal plan for a successful sync. The key to this going smoothly is good communication and involving your SFDC team from as early in the process as possible.  I also suggest that you continue that relationship by having regular meetings to discuss, not only the sync, but ways that you can improve your data. Because at the end of the day, these people aren’t just the dragon guarding the gold, they are also the wizards that can help you manipulate the data in very creative ways.

As you may know, two things uiniquely identify your instance of Marketo. They are...


  1. Your Munchkin ID - A string in the format ABC-123-DEF which you never typically have to be concerned with, but you'll notice that it appears in your Munchkin Javascript code and allows Marketo to associate anonymous activity with your instance properly.
  2. Your Account String - Typically a variation on your company name and either sandbox or production. Examples are
    • MarketoProduction
    • MarketoSandbox


When you talk to support or consulting a typical question is "what is the account string". Knowing this, we can access your instance and diagnose any issues you're having or work on your instance, which comes in handy!


There are times, however when you might need to change your account string. Your company might purchase another company that also has a marketo instance, or you might spin off a division that is using a Marketo instance.. and there are times that you might simply need to change the name for branding purposes.


It's important to note that your customers dont really see your account string, although that wasnt always true. At this moment, an account string is purely available to address revised company internal branding (spinoffs, etc).


Even links to assets within Marketo no longer use the Accounts String. Instead.. they use the Munchkin ID (which, as a side note, CANNOT be changed) and more important,y, they use your Landing Page CNAME.


So, assuming you have set a CNAME, which is very strongly recommended, when your account string changes, NO FURTHER action is required on your part.. links remain the same.


Example for Account String "mktodemoaccount181"

Native Landing Page URL:

Landing Page URL with CNAME:


Example Asset URL:


Screen Shot 2015-09-21 at 5.52.22 PM.png

In previous entries in this blog series, I've demonstrated how to upload custom object data into marketo using REST and SOAP.. but did you know its also possible to upload data in bulk.. from the Marketo UI, just like you'd upload Lead Data? It's true, and its really cool. The addition of this feature truly brings custom objects within reach for even non technical Marketo users.


If you recall, when we last left our hero (that's me)  We'd created an Automobile object using the new Custom Objects Interface. Since then the Interface has stealthily shifted around a bit, while maintaining the same functionality.


Fig 1: The Automobile's Definition



Fig 2: The Automobile's Attributes



Next up is creating an input file, and here's our sample.

Screen Shot 2015-09-11 at 4.58.15 PM.png


Great! The process is a LOT like uploading bulk leads actually, but here's how it looks. Start out in the lead database under New-->Import Custom Object Data


Select your input file, and choose your options. My file was text, autodetected, and Ive chosen to tell Marketo to use my dedupe field and a link field of email address, which is great for inserts and updates. You can also choose the MArketo GUID as the dedupe mode.

4.pngThen.. map the fields to the object fields...






Now you can see the objects in the lead details.


Cool, right?

Sometimes I wonder about random things. Like the exact behavior of random sample. In case you are also curious about these kinds of things, I thought I'd share some results of a few tests I've done with random sample.


Does random sample work for trigger campaigns not just batch?

I tested this out because I wanted to understand whether or not I could essentially split a set of incoming leads in even groups even if they were going through a trigger campaign. For example, I might use this if upon hitting MQL, I wanted to ‘round robin’ leads and send each of X number of salespeople an even number of leads, except all leads would hit MQL at different times so a batch campaign would not be appropriate.


I ran a test with a trigger that, upon lead creation, added a random sample of 50% of leads to List 1 and the rest to List 2. I did one test list import with ~180 leads and then did a second test list import with ~180 different leads.


Total list counts after completing the two imports:

  • List 1: 183
  • List 2: 182


The results tab of the smart campaign in question looked basically like this:

It was clear that even though it was a trigger campaign, Marketo had alternated adding the records to the lists. This shows the transition between list 1 and list 2 (based on Yahoo versus Hotmail email addresses) and you can clearly see that even though the Hotmail lead came in on a different list a few minutes later, it remembered where it had left off.


I then created several Gmail test leads manually and several AOL leads through form fill to confirm the behavior was the same, which it was.


So yes, random sample works exactly as you might hope for a trigger campaign.


How does random sample work when your lists have an uneven count and does that vary with and without using the Default Choice?

I ran some tests to figure out what happens when you’re running random sample against a list of uneven lead counts. For example, if you have 3 leads and you run a random sample of 50% to each of two lists, what happens to Lead #3?


Initially, this stemmed from wondering whether you might leave off leads if you set your random sample up like this:


Although these add up to 100%, what happens if you had 101 leads on the list? Do you get the same results as if you set up your random sample like this?

These were tested as a batch campaign run.


Count of Original Leads

Random Sample Setup



Choice 1: 50% to List A

Choice 2: 50% to List B

Default: Do Nothing

As you can see, two leads were added to list A and one was added to list B.


Choice 1: 50% to List A

Default: to List B

As you can see, two leads were added to list A and one was added to list B.


Choice 1: 33% to List A

Choice 2: 33% to List B

Choice 3: 34% to List C

Default: Do Nothing

As you can see, four leads were added to list A, four to list B, and three to list C.


Choice 1: 33% to List A

Choice 2: 33% to List B

Default: to List C

As you can see, four leads were added to list A, four to list B, and three to list C.


My conclusion is that it does not matter which way you set up the random sample (using default choice or not) from a functionality standpoint. Marketo always runs through and evaluates each lead on the list and never leaves one off. (However, I would still choose to use the Default Choice rather than three choices in this scenario.)


As an interesting aside, I ran a quick pivot table to see how many times in my five runs through the 33% example a lead got added to which list to see whether it was truly randomly selecting individuals, since the results log were always adding in order. You can see that there’s a large imbalance here - people would almost always end up on the same list in each run, but not always.




Of course, my tests are not statistically significant or anything, but I feel reasonably confident that I could base my campaign design off this info. If anyone else has suggestions or test results on random sample, feel free to share. Inquiring minds want to know!

The decision to migrate to Marketo from another marketing automation platform is one that I know must keep marketers up at night. How do we move all of our emails that are in-flight without a hiccup? How do I handle reporting on activities that happened in my old system after I move to Marketo? The list of questions is seemingly never-ending. The truth is, that there are six simple steps that can make your migration to Marketo nearly painless.


  1. Inventory EVERYTHING – You heard me, EVERYTHING. If you are using Marketo Professional Services, your consultant or project manager can get you a spreadsheet to use, but if not, you can do it yourself (just be sure to put a column in there for “sunsetting,” that will be helpful for step 2). Just like when building a program, start backwards, so you will start with inventorying your creative assets (images, pdf’s, etc.), then your forms (making note if there is any special functionality), then you will inventory your landing page templates, then landing pages (taking note of which template is used, and which creatives are necessary).  Up next you will inventory all of your email templates, and then all of your emails (as with landing pages, make sure you document which template and creative assets are used). Finally, you will start on your programs. This is where inventories can feel daunting, because they have so many moving parts. Honestly, this is the best way to become intimately familiar with your marketing automation operation. First up, start with your marketing programs. It is important that when taking your inventory, you document the smart list (who the program impacts) and the flows (what the program impacts). Don’t be afraid to put screen shots in of these things either. If you are using complex nurture programs, I suggest creating a separate tab just for nurtures, so that you can fully document them. Finally, you will move to your operational programs, these will mostly be your scoring and data management campaigns.
  2. Sunset as much as possible – Do you REALLY need to keep the holiday e-card that you sent in 2012? Probably not.  Unless something is actively in flight, it’s ok to archive it and let it go. I have done a ton of migrations from other platforms to Marketo, and invariably, the inability to let unnecessary assets go, eats up more migration resources than nearly anything else. Check out your metrics on old landing pages, if you are getting only a handful of views a year, it’s probably time to put it with the holiday e-card we just archived.  Note that I have consistently used the term “archive”. We are NOT deleting anything. I repeat, we are NOT deleting anything.
  3. Prioritize everything else – So you decided that you ABSOLUTELY needed the landing page for your St. Patrick’s Day Party from 2013 migrated to your new instance, but it is probably not as important as the new whitepaper that you just released last week that you have spent $100k in marketing dollars promoting… place your inventory in order of priority, from highest to lowest.
  4. Establish a clear naming convention for EVERYTHING – I know it seems elementary, but you would be surprised about how much easier it makes everything, not only migration, but also adoption of your new platform… with a clear and established naming convention, suddenly everyone becomes much more efficient. Now, Marketo certainly has some recommended best practices for naming conventions, but really, I don’t even care if you follow that, just follow something, and make sure EVERYONE follows it. You will thank me later.
  5. Start preparing redirects early – If you are like most clients, you have a ton of landing pages that will all need to have redirects set up by IT. Have this list ready to go by including a column on it in your migration sheet under the Landing page tab.  If you place it directly next to the existing URL, your IT person can easily copy and paste what they need to get your redirects up and running so that no one ever has to see a “404 error” page.
  6. Don’t be afraid to ask for help – OK, now you have a crazy-thorough inventory of your entire marketing operation… this is where it can start to feel overwhelming. Most people think they only have a few emails and landing pages, but when they start documenting it, they realize they might have hundreds or even thousands. Don’t be afraid to ask for help, engage people on your team, hire consultants, bring in interns, it doesn’t matter, but one person should never try this on their own.
  7. TEST everything, REWARD yourself, and FORGIVE yourself – OK, so I know I said 6 steps, but think of this one as a bonus… Before you go live, test every link, sample every email, and QA every program. You are going to miss something. I have done a TON of migrations, some of them very rapid (5 days is my record), some of them more relaxed (2 months is totally cake after doing a 5-day migration), but invariably, no matter what, something ALWAYS gets missed, and that is ok.  With all of your advance work in steps 1-5, the overwhelming majority of your programs and assets are going to be working smoothly and you will be able to quickly react to anything not up and running on day 1. Then, at 5pm on the day you launch, take your team into your office, pop open a bottle of champagne, and celebrate.  You totally earned it. Migrations are hard, and you just saw your marketing team through it mostly unscathed (Bob in demand gen is actually smiling, and not because he is about to snap!).


Seriously, migrations aren’t that bad if you are prepared, you aren’t afraid to get your hands dirty, and have a network of support to help you through the process. There are even twisted individuals like myself, who actually ENJOY them… and yes, I still celebrate with a bottle of champagne after every single one goes live.

We've been busy over at creating content to help you develop and improve integrations with Marketo.  Here's what we've been up to over the past month:


How to Specify Lead Partitions Using the REST API

Developer Evangelist David Everly provides a how-to in managing lead partitions through the REST API.  A must read for anyone developing for Marketo Enterprise Edition instances.


Best Practices for API Users and Custom Services

I go over the best ways to manage your users and services with respect to API integrations.  Following these guidelines will allow you to isolate usage counts from your third-party services, and revoke or restrict access by a service without interrupting any other services.


Add SalesPerson Data to Marketo

I go through the basics of synching salesperson records to Marketo, along with some sample code.  This is essential knowledge for anyone working with non-native CRM integrations, streamlining the process of adding owner-level fields to your lead records in Marketo, and allowing you to keep changes local to individual salesperson records, instead of updating all of the leads owned by that person


Updating Lead Data in Marketo Using the API

Dave covers the use case of bidirectionally synching lead data with the REST API.  Incremental synching with REST has a new model, so if you're new to building one, or have experience with the SOAP API, you'll want to check this out. Sample program code in Java is provided.


In addition to the recent blog posts we've overhauled and polished the documentation for Munchkin, Webhooks, and Email Scripting.  You can get content updates from the developer's blog through our RSS Feed or by following us on Twitter, @MarketoDev.

I'm spending a few hours this morning updating a playbook for one of my clients (you know who you are!) and it reminded me of this situation I encountered recently with another client.


This client is a division of a very large enterprise, which uses Marketo in many of their divisions. This particular division had a fairly saavy Marketo user, but he got promoted to a different role and no longer works in that division. The new individual brought in had no previous Marketo experience and no understanding of how or why their system was set up a certain way. Unfortunately, nothing is documented. We're now going in to help her understand what's been done in the system and make improvements, but as you can imagine, that's going to end up being more costly than having spent the time and effort in documenting up front. It's not that easy to decipher why someone else did something and even if some of the people are still around, your memory may not be as sharp as it was when you first set it up.


We see this story all of the time, and it's even worse in our SMB group, where Marketo knowledge often lives with just one single person in an organization. If that person leaves, it can be very hard for a new hire to figure out how things are working. So if you are that one single person in your organization, do everyone a favor and spend a few hours a week for the next few weeks and start documenting the way you set things up. You may be asking, well, why do I care what happens after I leave? I think of this as one of those "pay it forward" kind of things. If you do it, you're helping out other people in the Nation and perhaps when you go into your new role, you will discover that your predecessor has done the same for you. But it's not only useful in case you leave, but also in case you are so successful that you get to bring on a new hire and you need to get them up to speed on your instance. Foundation training is great but it will never be able to explain everything about how to use your specific instance.


If by this point you are convinced, here's some things to consider adding into your playbook:

  • Admin setup (workspaces, partitions, channels and tags, user roles, technical setup)
  • Governance (naming and foldering, data management, subscription management)
  • Program and asset templates and creation process
  • Lead lifecycle and routing
  • Program setup requirements
  • Ongoing nurtures or other programs
  • Testing and reporting
  • Integrations
  • Resources
  • Internal processes, such as those for changes or support

With the Marketo-Dynamics native integration, it’s really important to understand how adding new fields into the sync works, because it’s not always intuitive and it has an impact on your ability to use data in Marketo.


Scenario 1: You Enable the New Field to Sync to Marketo Before the Initial Sync

The second step of the sync setup is to choose which fields you want to sync from Dynamics to Marketo. If you enable a field at this point in the process, then when you do the initial sync, all existing data in that field will sync over to Marketo. The field will be kept up to date between the two systems going forward based on the rules you’ve established with field security and field update blocking.


Scenario 2: You Enable the New Field to Sync to Marketo After the Initial Sync But Before There’s Any Data in the Field

This scenario happens when you create a brand new field in Dynamics and you want to sync this to Marketo. For example, this might be the Lifecycle Status or Behavioral/Demographic Score fields that you often create specifically for your lifecycle processes. If you create the field, then go into Admin and enable the field to sync, and only then start populating the data, any changes made to the field going forward will sync over based on the regular rules.


Scenario 3: You Enable the New Field to Sync to Marketo After the Initial Sync When There’s Already Data in the Field

This scenario happens when you later decide that you need a field from Dynamics over in Marketo for marketing or sales purposes. Sometimes this happens because you didn’t do a really thorough job in your initial field selection or because your needs change later. This is where you really need to pay attention.


Data already in that field will not sync to Marketo until the data is updated for that specific lead in that specific field. To make this clearer, let’s take an example. I forget to sync over my custom Country field until after the initial sync. I have two leads – Jack and Jill. Jack does not have a Country value populated at all. Jill’s field already has United States populated. When I enable the sync for this field, both Jack and Jill will have empty Country values in Marketo. If I go in and update the Country field for Jack to United Kingdom, his record will get updated in Marketo and now Jack’s record says United Kingdom. Jill’s record is still empty in that field. If I go in to Jill’s record and I update her job title, her Country field in Marketo will still be empty. Only once I update the actual Country field on Jill’s record will that populate.


This situation obviously can present a problem for marketers. Obviously the best case would be that you thought through your field list thoroughly before you did the sync and you erred on the side of syncing over all the fields you thought you might use. But since that’s not always possible, here’s what you can do if you think you will end up in this third scenario:

  • Manipulate the data in CRM, such as:
    • Export the data from that field in CRM and then delete it in CRM. Then, enable the field in the Marketo sync and reimport the data from that field back into CRM.
    • Force a fake update to the field on all records, such as appending a . or – and then removing it after the update has synced over to Marketo.
  • Contact Marketo support to do a force resync of your CRM data.


When in doubt, you should always check with consulting or support to make sure you understand the implications of the actions you’re taking with the CRM integration. It’s much easier to change course in the beginning than go back and fix it later!

I feel very strongly that if you do not have the time to test a lifecycle (or money to pay someone else to test it for you), you shouldn’t be building it at all. The revenue cycle model and associated program are one of the most complex pieces to get right in Marketo. Having a poorly working lifecycle process is worse than not having one at all! You don’t want to ruin your relationship with sales by routing leads backwards from SQL to MQL.


So, assuming you are going to test, here are some suggestions of things that you should do before, during, and after the testing process to ensure you do a thorough job.


Before Testing

  • Make sure the CRM administrators are aware that you are going to be doing testing and this will involve creating fake records for leads, contacts, accounts, and opportunities. If they aren’t comfortable with this and want you testing on Sandbox, find that out before you build everything in Production.
  • Develop a list of scenarios to test each campaign in your lead lifecycle and have your CRM administrator and Marketo power user review it if possible.
    • Create scenarios to test all potential sources of new leads - list imports, form fill-outs, manual creation in Marketo, creation in CRM as a lead, creation in CRM as a contact, and creation via the API if applicable.
    • Develop scenarios to test things that do and do not create a score, if you are using scoring to move leads forward in lifecycle. The same applies to status changes.
    • Pay careful attention to long wait steps. Consider what would happen if the lead changed in some way while in the wait step and make sure you’ve accounted for this properly.
    • Think about activities that might trigger multiple campaigns and somehow trigger a lead to move backwards in lifecycle. Score changes and status changes are big causes for these problems.
    • Don’t forget scenarios to test leads created in partitions as well as those moving into other partitions if you are using workspaces and partitions.
  • Make sure your revenue model is using the manual stage change trigger for all the transition rules.
  • Limit all lifecycle campaigns to only apply to a test list.
    • I recommend making a smart list with “Email Address is”, which allows you to add test records to your list as needed. Then place the filter for Member of Smart List in all of your lifecycle campaigns.
    • Pay careful attention to Advanced Filters that will need to be adjusted as you add another filter.
    • Include way more potential test records than you anticipate needing and use a standard number format to vary them. (e.g.,, etc.)
  • Update all alert and escalation emails so that they are going to your fellow testers, not other marketing or sales people. Check both the Lead Owner dropdown and the email address section of the send alert to make sure you’ve removed everyone who shouldn’t get it.
  • Update the CRM sync step to sync to a different owner (if necessary).
  • Update all long wait steps to something reasonable for testing (on the order of 5 - 30 minutes instead of days, weeks, or months), but giving yourself sufficient time to make positive or negative changes to statuses or stages (or receive updates from CRM) so you can test your scenarios.
  • Create a tab in your lifecycle testing document for recording the changes you make to each specific campaign and specify exactly what changes you’ll need to make after you are done. Trust me, you won’t remember by the end of this.


During Testing

  • When possible, test in person with someone with CRM administrative access and the primary Marketo administrator. A standard acquisition lifecycle takes approximately two full days to test thoroughly for an inexperienced tester. If testing in person is not possible (hours, travel, etc.), schedule 2-3 hour test sessions daily until complete. An hour is not sufficient time to make progress due to set up time and sync speed.
  • Record the email address of the test records you are using for each scenario.
  • Detail out each step that you’ve taken in the results column. This will be especially helpful if you are testing multiple scenarios at a time (because you are waiting on something) or if you are troubleshooting because something didn’t work as intended.
  • Don’t test too many things at one time. I would recommend testing no more than 2 - 3 things at once. Not only do you want to avoid making mistakes because you’re distracted, but your co-testers will get lost and confused if you are jumping around too much.
  • If you are still waiting on some results or some of the test scenarios do not apply, mark them as Waiting or Ignore or some other status so you can clearly see what you need to return to later, especially when testing over multiple days.


After Testing

  • Remove the test list from all of your smart campaigns.
  • Update all of your wait steps back to their original timeframe.
  • Adjust all of your alerts and assignments back to the original owners.
  • If not going live right away, deactivate campaigns.