CiviCRM Community Forums (archive)

Have started drafting a new section in online event registration documentation that deals with duplicate matching and updating already existing records.

I appreciate your summarizing this as I've just started using CiviEvent also and all these questions came to my mind as well.

Does anyone know the answers to the questions posed in the documentation?

You can define the rules for deciding if this contact already exists [how? Are the duplicate checking rules used?].  By default, CiviCRM uses the email field to check whether a contact already exists (this field appears by default in any event registration screen).  You can turn this behavior off [how?] [http://forum.civicrm.org/index.php/topic,4184.msg30443.html#msg30443] and use your own contact matching rules.

If the user is logged in, information from their contact record will be automatically populated in the event registration screen.

In particular, is it possible to turn off or change the duplicate detecting behavior?

For instance, in our use-case our user data is cleaned & standardized in various ways & so we really don't want people just changing (even their own) data willy-nilly.

Even something as simple as lazily entering the address in all lower or all upper case will cause us problems down the line.

What would be preferable, would be to have all Events info entered as new contact entries, which we could then go & manually search/merge duplicates if and when we want.

Also, for example, it's quite common for someone to pay for an Event on behalf of another person.  That's easy to handle via CiviEvent now (it automatically collects billing info & then just collect name/address of participant via a profile).  So then that entry has a separate "home" address and "billing" name & address.

That's perfectly fine for the CiviEvent entry but we certainly wouldn't want that person (and his/her billing address) entered as the permanent billing name/address for that membership record! Just because someone paid for someone else's event fee one time doesn't mean they are going to pay for all that person's memberships & donations every time from here on out.

Any thoughts or ideas on this topic are welcome!

If it is contact / location information you are interested in collecting using this profile, another approach might be to create a new location type for a contact and expose this in the profile.  So the activity is associated with the contact, but you won't over-write the contact / location information.  Not sure if that would fit your use case but might be a good strategy for some.

I haven't tested this so would welcome feedback from people that have