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 ...
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....
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 ...
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 location type you'...
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 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 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 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::...
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.
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.
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.
One way of resolving this might be for all the contact auto-complete widgets to reuse the same format as quick search (in the top menu bar). The setting is user configurable here:
(search for Autocomplete Contact Search)
This probably is a good change to be made in core
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.
Here is the commit originally made to fix that issue. I suggest you check the current version of the code to ensure that function is still working - seems possible that it may have been inadvertently broken during some restructuring around the way contact ids are stored.
I think this pull request, that was merged into 4.7, contains at least some of these improvements. But not the functionality from the extension (as far as I know):
Check out the new functionality on the demo site, and see if it meets your expectations.
They are merged, based on the "Unsupervised" deduplication rules: civicrm/contact/deduperules?reset=1
By default the unsupervised rules for individuals are based on email-only.
So if someone fills in a Webform with an email that already exists in civicrm then those data will be merged.
You can change these rules: http://book.civicrm.org/user/common-...