Why you should always use a static list to import persons in a program

[Grégoire_Miche2]

I often get the question about why one should not import persons in programs (using the "import members" button in the member tab:

There are at least 3 reasons for this:

1. Because you want to be able identify without any doubt which persons where created on lmport and which were merged with existing persons.
2. Because you want to be able to control program membership and acquisition information
3. Because you want to control order of operations in an SFDC environment

Let's explain in details:

1-Being able to identify which persons were created

There are many way to identify persons that were created from an import, but most of them can give inacurate results because they are based on information that can be tempered with. Acquisition programs, source, and any other field based identification can be tempered with with simple flow steps, errors in Marketo from the user, or changes in the CRM.

You can protect your database against certain changes (for instance blocking updates on fields), but you also have another issue to deal with: the source or acquisition program will be the same whether a person has been imported in the program or if the person filled out a form (see ) In this case, a filter on "acquisition program" will give wrong results.

And yet, in some case, you need to accurately identify the persons that were really created on import, in oder to be able to delete them (and only these ones) later on or in order to run specific campaign (such as add the to an engagement program).

The static list here is very helpful since the "person is created" filter and associated trigger provide a very useful "List name" constraint:

Using that constraint, you can select precisely the persons that were added to your database through the list import.

2-Controlling program membership and person acquisition information

Importing a person in a program makes it a member of of the program and automatically sets the acquisition program and date if the lead is created upon import. But sometimes, you need control these information. For instance, you may want to run an email on the imported database and consider a member or even an new name only the valid emails or the persons who click it.

Unlike what is written is some places, importing in a static list within a program does NOT make the imported persons a member, nor a new name of the program. You will have to run flow steps to make it happen, which means you will be able to control precisely the conditions for this to happen.

3-Controlling order of operations

This really matters if your program is synchronized with a SFDC campaign. In any other situations, this point will not be valid. And this is a consequence of previous point, but I though it was worth a separate chapter.

When you import a person in a program, that person is immediately added to the program as a member, and if the program is sync'ed with an SFDC campaign, the person is also immediately pushed to SFDC, denying all your data management and person lifecycle management campaign to run. This results in mis-assignment, wrong alerts, etc... some workarounds exist but still*, but this is not a welcome behavior.

If you use a list to import the data, then you can use a "was added to list" filter or "added to list" trigger to process things exactly in the order you want and finally add the person to the program in the correct member status, and also set the acquisition program (I tend more and more to privilege filters and batchs for long lists, that I run after the import is complete: no need to add another trigger to the active list, since this trigger will only fire once).

4-Conclusion: to reduce user confusion, use only one method, the safest one.

I observe, across all the projects to which I have been participating, that teaching users multiple import techniques is more confusing than anything. On the long term, they tend to forget about the pros and cons of each methods and fall back on using only one.

For these 3 reasons, I strongly recommend that you get used to have an "Import list" and the associated smart lists:

• Was created on import
  
• Was merged on import:
  

-Greg

* Add a "Sync is authorized" field in SFDC that has to be true in order a person to be inserted from Marketo (using an SFDC validation rule to control this), but sometimes

[Dan_Stevens_]

Thanks Greg - makes sense (and thanks for the detailed write-up).  Although point #2 isn't as relevant for us since we don't (and can't) sync to MSD campaigns.  In point #1, I can see how this would further help identify those leads that were entered in Marketo via a list import (vs. solely relying on Acquisition Program - which can be from a variety of sources (list import, organic, form submit, etc.).  I think where this approach really adds value is automating the progression of program statuses - like we do sometimes - by keying off of a field that's included in our "campaign/event responses" Excel templates that the field marketers submit for processing.  So instead of importing via the "import members" feature and then manually changing the program status of specific leads once they're members of the program, you can use automated flow steps like this:

which then qualifies them for other trigger campaigns in the program:

Again, thanks for providing more detailed around this approach - it's definitely in line with what we're moving toward to further enhance our processes; and make them more efficient.

[Grégoire_Miche2]

Hi Dan,

Yes, thx a lot for this excellent add-on to the post!

And hopefully point #2 will one day become relevant to MSD, once Marketo-MSD connector supports MSD campaigns

-Greg

[Brian_Law_MKTO]

Thanks for the great comprehensive post Grégoire. Awesome stuff. Here are two related articles written by Marketo employees:

Choosing the Right List Import Approach and List Membership and Program Membership - There's a Difference

[Grégoire_Miche2]

Hi Brian,

Excepted that I do not agree with what is written in these articles: importing directly into programs causes quite a few issues and is usually not the best approach. Furthermore, my experience is that it is not a good practice to teach users to use sometimes one approach and sometimes another: they tend to get confused and, on the longer term, fall back on using only one approach, always the same, the one they feel the most comfortable with, forgetting about the potential drawbacks.

Therefore, I now only teach users one and only one: static lists in programs, so that they stay in control of what happens afterwards.

-Greg

[Grégoire_Miche2]

Updated the article to provide some more details, following some discussion here and in other related articles listed by Brian.

-Greg

[Brian_Law_MKTO]

Hi Greg, to clarify, I agree with your approach. I am also not a huge fan of importing directly into a program. I agree with your recommendation that people should use one approach. Using multiple methods can make things confusing and cause someone to make an error. Thanks!

[Anonymous]

I have been using Import Lists in my Architectures for years now. My approach is that anything which creates an entry point into Marketo for new leads should be tied into Operations which trigger on entry. I'm still pleading my case to my firms owners to primarily work from Master Import Lists and let operations do it's job to identify, update, add, and parse, while using Smart Lists for specifics verses creating 100s of static lists/import programs. Below is how I'm doing it in a multipurpose Instance that's LDB currently is 95% small list imported leads (client names redacted for client privacy). This is from when I activated and rolled out the first purposed set of programs. FYI - In the case of companies who rely heavily on list imports for lead generation and who tend to import larger lists, I add a customized load balancing program as well to prevent bottlenecks in operations on import.

Dedicated Import Lists:

List Import Operational Programs: