Here's an example of a very common situation I have:

  1. Database has a contact like this

    • first name: Robert
    • nick name: Bob
    • last name: Smith
    • email: bobsmith@example.com
    • ...
  2. Event registration form receives a submission like this

    • first name: Bob
    • last name: Smith
    • email: bobsmith@example.com
    • ...
  3. A duplicate contact is created because the first name values do not match.

When finding duplicate contacts, is there some way of getting Civi to notice that the first name of one contact is identical to the nick name of another contact?

As a workaround, I've tried adding the nick name field to public forms, but trust me you don't want to do this. It's funny seeing what people write when prompted for a nick name, but not so funny when you notice postal solicitations addressed to people like "The Dude Smith".

  • As an alternative workaround, perhaps the dedupe rule needn't consider first name? Are you getting a lot of unsupervised dedupe interactions where 2 folks share an e-mail address and last name? Apr 13 '15 at 18:59
  • Good thinking, Jon, But I definitely have a lot of cases were different people have same email and same last name.
    – Sean
    Apr 14 '15 at 1:39
  • Yeah, the problem is that most people who share emails (or phones, for that matter) in general are family members, often with the same last name.
    – Andie Hunt
    Apr 14 '15 at 11:48

You can create a view only custom field that you set with a civicrm_post hook when contacts are created/edited. It has the value of nickname if nickname isn't null, else first_name. Use that field in your dedupe rule.

  • Clever. It seems like this would fix my example case, which I like. But it also seems that it would break other cases (that currently work) where the contact would fill out a form using their formal first name, e.g. "Robert". So in the end, unless I'm missing something, it seems like this approach would be one step forward, and one step back :/
    – Sean
    Apr 23 '15 at 12:51
  • 1
    @SeanMadsen - Good point. The answer: Match on first name, the custom field as 1 point. Set last name as 2 , and set the dedupe threshold to 3. That will satisfy both use cases, and avoid collision between "Robert Bob Smith" and "Robert Bob Jones". Apr 24 '15 at 4:38

This isn't going to help now, but big-picture, there ought to be an aliasing system for names. This Nickname problem occurs for organizations in an even bigger way, and Legal Name won't match with Organization Name.

What ought to happen is that Nickname should be considered an alias of First Name, and you could have multiple aliases for it. Someone could set up a maiden name as an alias of the last name, for example. On the organization side, aliases for Organization Name could bypass all kinds of relationship chaos that happens when people set their Current Employer.


I'm testing this dedupe rule out. It must match both partial first name (3 characters) and last name and either email or phone.


  • This catches cases like "Rob" -> "Robert", "Dan" -> "Daniel".
    – dsmith63
    Oct 22 '21 at 17:20
  • but not "Bob" > "Robert, "Tony" > "Anthony" or "Mandy" > "Amanda" unfortunately
    – petednz - fuzion
    Oct 22 '21 at 17:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.