In Mailchimp one email address corresponds to one subscriber. However in Raiser's Edge this is not the case. One constituent can have multiple email addresses. One constituent could have multiple email addresses using the same type as shown below:
Or they could have different email address types
Some organisations are only interested in sending the primary email address over to Mailchimp. (Some of these organisations have a "Mailchimp" email address type to make it very clear as to which one should go)
How does Chimpegration Classic handle a situation where an organisation wants to send over multiple email address types?
Chimpegration Classic only allows you to export one email address from a constituent at a time. This means that your export (and we always recommend using export when there is the possibility of multiple email addresses) needs to distinguish between the different email addresses. This is simpler to do with the second scenario where the email address types differ but much harder, almost impossible with the first scenario. It is possible to select the primary by sorting by primary in the export as shown below:
And consequently it is possible to retrieve one of the other ones that are not primary by sorting in the other direction.
Why can I not just export more than one of my emails?
You could do this
but there is no guarantee that they would always some out in the correct order.
What you need to do instead is to export the three items as separate nodes on the export, each with their own selecting criteria:
In Chimpegration Classic export you need to run the export three times each time mapping to a different phone type as shown below
This will then create three different subscribers in Mailchimp. So far so good.
They all have the same constituent id. Is that a problem?
In short for some other processes it is a problem but for others it is not.
In manage campaigns, as long as you realise that if a user unsubscribes they are unsubscribing from a specific email addresses and not from all email addresses. This means that the change you make on their record should only affect the email address and not the whole record then this will not be a problem e.g. you could set the email address as inactive or change the type to "Unsubscribed". The problem with this is that when you run a query in RE to determine who to send emails to you will need to include criteria that checks to see if the user has an email address that is not inactive or is not of type "Unsubscribed". If you are relying solely on Mailchimp to determine this then this is less of a problem as when a subscriber unsubscribes, you are no longer able to add them unless they resubscribe themselves. So it would not be possible to put them back in the list even if they do appear in your query.
If you are adding actions for opens then the opens and clicks will be aggregated into one action. There will not be a separate action per email address. Likewise if you add an attribute, appeal or solicit code. You will not get multiples.
Synchronisation is a greater problem. Synchronisation always works with constituent ids.
When constituents have changed on RE then the comparison will only be made with one subscriber i.e. the first one that Chimpegration finds.
When subscribers have changed on Mailchimp then the comparison can be made with both subscribers as Chimpegration treats each change in the subscriber separately.
When both constituents and subscribers have changed since the last run time, Chimpegration calls this a conflict but it will only work with the first subscriber which has a corresponding constituent id.
What this means is that in some cases changes that have been made will not be properly synched between the two systems.
In Summary
In summary, Chimpegration Classic does not support this scenario effectively. We may develop functionality in the future to cope with this but there are a lot of variables to consider. If you would like to share with us how you would overcome these issues from a process perspective then please do get in touch.