There are several circumstances when you can end up with two membership records for the same person.
Sometimes this is desirable: they are in there with different roles, perhaps different email address etc. In this case they can be linked to show they are the same person with the aka field.
But sometimes they have just managed to get in there twice. For example, their membership lapses and they use your joining form to rejoin, rather than renewing. Or they sign up to something as a contact when they are already a member. In these cases, you’d want to merge the two records.
For new memberships, in the Enrol section, Cameo tries to detect if the new member also has an existing record and if so to offer them for merging. You can also do this for all records in the Manage Duplicates section.
What is a duplicate?
If you know a pair of records are duplicates, you can always locate them manually and perform a merge. However, for automatic detection we look for records with:
- the same email address appearing in both records, or
- the same postcode and last name of one of the individuals
What does merge do?
It depends. The strategy, in order of importance, is:
- to prefer membership types and numbers over contact
- to keep the oldest membership number and qrcode
- to prefer newer information over old
- to merge compound fields like address, individuals and list subscriptions
In Manage Duplicates, you get pairs of potential duplicates with the newest first (that is, the one with the later joining/added date). When you merge A (the first) into B (the second):
- most of the information from A is carried over into B
- list subscriptions are merged
- addresses, gift aid declarations and bank references are retained from B if A doesn’t have them. For addresses, if A just has a postcode and B a complete address, the complete address is retained if the postcodes match, otherwise just the newer postcode is saved
- usually B retains its membership number and qrcode. An exception is that when A is a current member and B is a contact, the membership number and qrcode is taken from A, the reasoning being that extant memberships are more significant than contacts.
- the type of resulting record is usually that of A, except when A is a contact and B isn’t, when it is taken from B (memberships outweighing contacts).
Membership number and type
Here is what happens to membership number and qrcode (#) and type (T) in a merge, depending on the input types (of A, typically the newer joined date, and B, the older):
|A ↓ B →||new||current||old||contact|
Those in this row will most often be picked up in enrolment, not de-duplication
They appear to have tried to join twice, perhaps they are impatient. Info from the later one but number from the earlier.
Reflects a mistake: they tried to join when they are already a member. Typically they got lost finding the right form, having failed to follow the link provided to renew. We just update with newer information. A manual renewal would quite often also be required afterwards.
Very common: someone lapses then rejoins, so we reinstate them, with the new information (e.g. a new email or address), but their original number
Very common: someone joins after having been a contact. We keep the number they were previously known as (one could argue the opposite, but it probably doesn’t matter much), but use the newer information, and as we’ll want to do the normal enrolment, the result is new
Rather odd situation – we have a more recent current membership than a new application.
A case that should never have got like this: we’ve managed to get duplicate current members. Newer information takes precedence, but longer standing number survives
Arguably should not be allowed. Why would this ever arise?
|# A |
This gives the membership priority over the contact, which is both newer and more important, doing little more than merging list subscriptions (though the address would also be carried over from B if A doesn’t have one)
|old||not allowed||not allowed||not allowed||not allowed|
Slightly unusual: they also signed up separately as a new contact before you had a chance to process a pending member application for them.
So we still want to enrol them, just with any lists they added as contact merged in.
They signed up as a contact even though they were already a member.
In your case this probably reflects the fact that your membership data wasn’t available to update, or the form they completed doesn’t recognize the case.
In some cases this might be better done the other way round, but impossible to tell automatically. Either way round, this retains the current’s number, so it’s just about where the best data is.
They signed up as a contact having once been a member.
After the merge, you can always reinstate them, but this isn’t automatic.
Simple case of duplicate contacts. If this keeps happening, perhaps reflects on whether the form is doing the right thing?