When dealing with duplicate leads, Marketo should stay consistent on which lead record is considered the active/current lead

When dealing with duplicate leads, Marketo should stay consistent on which lead record is considered the active/current lead

If you have duplicate lead records in Marketo, it's important to know which record Marketo considers the "active" record.  Consider the following example:

Sending Batch Emails

If there are duplicates within your email list, only one email will go out. It will be the lowest Marketo ID (created first). This record is also used to populate tokens.  Example:



Marketo ID

First name












In this case, the email will be sent to the first record with Marketo ID 2749. It will say “Dear Elizabeth” if you use a token for first name. Also, the activity entries will be attached to that record (sent, delivered, opened, clicked). When the email click goes to a page with Munchkin code in it, any web visits will also be associated with this record.

[EDIT 1/30/2018]: apparently this is not the case.  As you can see below in the latest comments, Aaron Dear uncovered a serious issue/bug - especially if you have a lot duplicates in your instance (in some cases, these duplicates are intentional).  Basically, there is no defined logic to determine which lead record is used when evaluating duplicates as part of a batch email campaign.

List Uploads

When a lead is included in a list import and the lead already exists in Marketo, it will affect the most recently updated record in Marketo (updated last) - in this case, the record with the first name "Beth".  If you're intention was to ensure Beth's record had the most up-to-date information so that some of that info could be used in an email send, you're out of luck.  Marketo will use "Elizabeth's" record for that send.

We’ve been running into issues with duplicate leads that exist in the same lead partition – specifically when sending batch emails that include tokens for Sales Execs (BDE) First, Last, and Email.  To ensure this info is updated before an email goes out, the marketer will make sure the list import contains the most recent data.  The emails still went out with outdated content/data.  Uploading a list with updated data won’t matter (when there's a duplicate) since Marketo doesn’t use the most recently updated record in Marketo when sending out the email.

Obviously, the main objective should be to deal with duplicates appropriately and regularly.  But this often is easier said than done.

When duplicates exist, I would like to see Marketo treat the active record consistently - in this case, the same for when sending batch emails AND list uploads - so that we can be certain our emails contain accurate personalization data.

To see Marketo's full list of duplicate rules, head over to the discussion: If duplicate leads are an issue, be aware of how Marketo determines which lead is active

Level 10 - Champion Alumni

It's a good point and thanks for documenting this better than it had been in the past.

Level 10 - Champion Alumni

One option to remedy this would be to offer an option in the Qualification rules of a batch smart campaign (this last option does not exist - this is just a mock-up):


Not applicable

Dan, I love your suggestion.

Level 9

I love this idea too!

Level 10 - Champion Alumni

I think this requires it's own separate idea so that it's called out specifically.  Just added:

Level 3

Been doing some testing around this - my support guy pointed me here.

To clarify, email sends will go to Marketo's smallest ID. That is NOT always the one created earlier.

After a lead record has been deleted from database, Marketo will eventually start associating newer IDs to older records. For example:

1) A lead fills out a form. ID#100 is created.

2) ID#100 is manually deleted

3) ID#200 is created - same email address as ID#100.

4) 3 months later, a lead is created from a Salesforce list upload - same email address. When it syncs over, Marketo assigns that lead ID#100. This lead is younger, but has a smaller ID.

5) An email send goes out - both leads meet the criteria. ID#100 gets it.

Just a PSA!

Level 10 - Champion Alumni

Aaron - thanks for sharing.  But why would the lead created in SF use a lesser LeadID?  Is it because Marketo uses whatever pool of IDs that are available - and now #100 is available?  Somehow I thought that once a leadID was assigned - even though it was eventually deleted - that it wasn't available for re-assignment.  Have you confirmed this?

Level 3

I am led to believe there is a pool of available IDs from previously deleted leads that "frees up" after a certain period of time.

As for confirmation:

  1. I noticed it myself a while ago. I had 3 leads, with the older 2 (both in SFDC and Marketo age) having a high ID (6 figs), and the newer one having a lower ID (in the 40k's). Then, just recently, I noticed another set of leads with a similar M.O.
  2. I assumed that the ID was immutable. When I asked support (who then asked product) they noted that IDs begin from the lowest number after a certain period of time.
Level 10 - Champion Alumni

Wow, that's very concerning - especially from a privacy perspective.  For example if you reference LeadID in any sort of reporting or API calls - you're now using the data of an unintended person.

Level 3

Agreed. In our instance, we have tested using the API to surface Marketo activities into our CRM. While it works, the potential of ID swapping concerns me. We might just need some logic to refresh IDs every so often.

Here's the exact response I got from support:

Sorry for the misunderstanding, a lead ID can be reused if a lead is deleted and then purged from the instance. A purge occurs about 30 days after a lead has been deleted which is the window for support to be able to restore a deleted lead.

So most likely which ever lead had the value of 46460 was deleted and then purged which left a hole that was filled by the next lead to be created.

Keep me updated if you have interesting workflows/flows/processes/etc to get around it - or ways to guarantee ID matching to SFDC IDs!