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:
- Because you want to be able identify without any doubt which persons where created on lmport and which were merged with existing persons.
- Because you want to be able to control program membership and acquisition information
- 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
7 Comments
.png)