By default the Webform-CiviCRM module uses the default "Unsupervised" rule from CiviCRM to determine if an unknown contact is already in your database. If this is not happening for you, check your rule's criteria.
And as of v4.11 you can now specify the matching rule per contact.
You'll find this new option just under the "Contact Fields":
The help text ...
Its generally a contact with lower ID that's preserved.
For aggressive merges, fields in conflict are retained from that of higher contact ID. In other words, for fields in conflict, value from higher ID overwrites on that of lower ID.
Preserving of contact, is due to the way dedupe queries are written.
INSERT INTO dedupe (id1, id2, weight) ...
Perhaps the best free explanation of CiviCRM's deduplication is from the CiviCRM blog last year (July 31, 2014): Understanding CiviCRM Dedupe Rules
For the whole process, I will let the author speak for themselves as it really is an excellent write up and worth reading in its entirety to understand the deduplication system.
For this question, I suspect the ...
The External ID field isn't just a regular field--it allows matching by ID alone. It would be a waste to have External ID be concatenated fields, for a couple of reasons:
You can't search easily. If you have a contact with an ID from System 1 of "123" and an ID from System 2 of "789", and you concatenate with a "|", you'd have a value of "123|789". If ...
Welcome to CiviCRM SE.
You can merge the contacts manually via search results. Here is a link to the specifics:
You should also review the information on merging two contacts manually here:
Yes - go to Contacts menu » Find and Merge Duplicate Contacts. There is dedupe documentation available.
The tricky question is, "What represents a duplicate contact?". For some organizations, two contacts with the same record might be a duplicate; for others, that's not enough to determine if it's a duplicate.
So while the Using rules and merging ...
When you add the contact in the CiviCRM tab of the Webform, making sure you check the "Existing Contact" box:
From the help:
Gives many options for how this contact can be autofilled or selected.
From the Webform tab you can edit this field to configure:
Widget: Determine whether to expose this field to the form as an
autocomplete or select ...
On our site we simply created a new rule, and chose the 'Unsupervised' option when creating it.
That creates the rule, and marks it as the default 'Unsupervised' one. The old default is downgraded to a 'General' rule. If it was a built-in rule then it stays 'reserved' so you can't edit it.
I don't think there's any need to delete them, or fiddle in the ...
The import code's use of dedupe rules as of this writing (Civi 5.1) is...interesting.
The rules, which are defined in CRM_Contact_Import_Parser_Contact::getPossibleContactMatches involve short-circuiting the dedupe matching if the external identifier is a match. After that, it will ALSO run the unsupervised dedupe - and from there, run your dedupe as well.
2019 UPDATE: A year later, I had to revisit this problem space, and I improved on my old answer; ignore earlier discussion threads on this answer.
When deleting duplicated emails/phone/addresses within a contact, you're inherently losing data. E.g. if a phone number is both "Main" and "Work", and you delete one, you have to choose which ...
I have seen this when the uf_match table does not have the proper values for WP Id (uf_id), Contact ID (contact_id) and email (uf_name).
I don't know why this occurs, I've not been able to track it down, but I suspect it is when the uf_id and contact_id do not have the email in use by WP.
You can user API Explorer /wp-admin/admin.php?page=CiviCRM&q=...
An activity gets recorded when you merge and it looks up the target contact via that.
Use $winnerContact = civicrm_api3('Contact', 'getmergedto', ['contact_id' => $contactId]).
See also https://github.com/civicrm/civicrm-core/blob/5.20.2/api/v3/Contact.php#L1275
You don't say what version of CiviCRM you are on, and you do say this is occurring on both contributions and on event registrations, but I will note here (for those happening onto this related issue) that there is a bug in CiviEvent, versions 4.3.4, 4.4.3, in which the unsupervised matching rule is not used in event registrations. See: https://issues.civicrm....
Pete's answer should be correct, but reserved dedupe rules don't work like normal rules. The original assumption: First name, last name and email must all be identical - is correct.
Dedupe rules with multiple criteria work by running a separate query for each criterion, filling a temp table with the weights. This is flexible but inefficient, so the "...
You will want to adjust your Deduping and Merging settings (top menu > Contacts > Find and Merge Duplicate Contacts). See https://docs.civicrm.org/user/en/latest/common-workflows/deduping-and-merging/ for info.
If you're using the default rule that comes when Civi is installed, any contact with the same email will get merged automatically as you're ...
To merge 2 contact records, select both contacts from a list then select the action 'Merge contacts' from the 'Actions' drop down. In the resulting screen you will see there are several options that you can check/uncheck - one of the most useful ones is the option near the top of the screen to 'flip' the 2 contacts - the left hand one is regarded as the ...
So I looked at the civicrm email records of the two contacts that produce such an error and they look fine.
Alan figured out that this is a bug: during the merge process when data is being gathered about both contacts, code is verifying that the value is valid, but it does so after converting it to an option value (i.e. email is "2").
A quick workaround ...
You could upgrade your CiviCRM version (4.4) to the latest version (4.6+), which will display contact emails along with their names in the autocomplete, making it easier to distinguish between similar contacts.
You should go look at your civicrm_uf_match table in the database. If you ever cleared out users in bulk or moved from one site to another, you probably have entries in there for users or contacts that don't exist. The purpose of the tables is to link users from your CMS (the uf_id column) with contacts from CiviCRM (the contact_id) column.
You can change the email account associated with a WordPress (or other CMS) account by editing the "UFMatch". If you're SQL-savvy, the correct table is civicrm_uf_match. If you want to do it through the web browser, and you acknowledge that this is a tricksy maneuver, you can do this:
Go to Support menu > Developer > API Explorer. "Support" menu might be ...
I ran into a similar problem today. My solution requires some tech chops, but was very effective:
Install cv on the server if you haven't already.
Create a text file named forcemerge.php on the server anywhere in your webroot with the following contents:
// Set the dedupe rule
$rgid = 13;
$return = CRM_Dedupe_Merger::...
You can change a contact's type either by the API or (safer) using the contact-editor extension. Obviously once you fix the types the dedupe rules will work better for you - but I don't know of an easy way to search for dupes across types.
The short answer is no. Dedupes for individuals and oranisations are handled separately in Civi.
I'm assuming (and feel free to correct me if I'm wrong) you've got an event booking profile for an individual which includes the current employer field.
From Manage events list. Find the event in question.
From the configure options at the RH side of the screen ...
Demerit's and Mick's answers are incorrect for the (built-in) reserved rules - though it's definitely confusing!
If a RuleGroup has a value in the name field, and that name corresponds to a filename in CRM/Dedupe/BAO/QueryBuilder, then the customized SQL in those files will be used. The existing entries in civicrm_rule for those RuleGroups are holdovers ...
If you have hosting that allows you to turn on Detailed Logging, there are two extensions that provide address history. One is in Extended Reports; the other is Joseph Lacey's Address Log report. It should be relatively simple to extend either one to support phone/email/etc.
Another option, low-tech but effective, would be to export the contact details ...
If they create a Drupal account is there already a duplicate before they fill the Webform? If so, you may be able to use a Profile on the Drupal account creation page that matches contacts to prevent duplicates there -- at which point the webform should function as expected.