When an organization is creating a profile form for use either stand-alone, or as part of a event registration page, or as part of a contribution/membership page, there is not a clean/elegant way to collect information about other people, such as their spouse or children, or emergency contacts. If an organization creates a client intake form, they currently use custom fields to gather information about that client's spouse, emergency contacts, personal references, or other details.
When someone registers one or more people for an event, where they are not participating themselves, CiviCRM always treats participant #1 as the payer. If a parent is registering their 2 kids for school, kid #1 ends up with the email address of the parent.
In any case, no back-office relationships are created automatically. Instead the staff/event organizer must rely on the "registered by" id to see who all was registered as part of one transaction.
The following situations illustrate common situations where support for relationships is needed in the self-service areas of CiviCRM:
- An organization using CiviCRM offers many events and programs for children and teenagers. The event registration page asks questions about the children (the event participants) as well as the parent and emergency contact information for those children. If its a paid event, the parent will be the one filling out the form and paying the event fees on behalf of their children.
- An organization wants people to register for a fundraising dinner. The vast majority of people attending will be bringing their spouse or significant other, who is most often already in the database. Yet they have to fill out their spouse's name and other fields in the profile from scratch.
- An organization is providing a client intake form. They need to ask about the client, the client's personal references, and the client's emergency contact info.
- An organization has a membership join/renewal page. They need to ask about the member's spouse, children, and other contacts that are connected to them via relationship.
Requirements for the solution:
1) Easy method for administrator to create registration forms
Provide a straight forward method for the person creating an event registration, or membership contribution page to decide what fields they need to include for multiple people, and what relationships should be created. For example: The event organizer can choose which fields they need to collect for the child, and for the parent/step parent of the child, and for the emergency contact of the child.
Possible technical approaches:
a) When editing a single profile, provide tools to choose relationships, and fields for the other contact. There is already mechanism that does this in the CiviCRM contact import/export wizards.
b) Allow multiple profiles to be used within a single event/membership page, with tools for the person setting it up to specify relationships between the contacts.
c) the Drupal "WebForms" module already has integration with CiviCRM data, but can currently only be used for stand-alone forms. Perhaps WebForms integration with CiviCRM could be enhanced to be used within event/membership registration pages.
d) Enhance the CiviRelate module, which is described at: http://drupal.org/node/819840
2) Easily register your related contacts
If the person filling out the membership/event registration page is logged in, then they should be presented with a list of contacts they have relationships with. (ie their spouse, children, etc) each with a checkbox. Then they can check the box to register an existing child/spouse for that event/membership. For example: a parent would see a list of all their children and could check off which children are being registered for this event. For each child that they register, they could correct any fields that have changed. Such as the child has a new allergy.
Likewise, when someone is signing up for membership, she should be able to see a list of other related contacts (including her spouse and children). She can click on the checkbox next to her spouse's name, and then update her spouse's cell phone, or any other details for the spouse that are exposed in the memberhship profile.
3) Easily add new contacts to their household/relationships
Some examples: A brand-new person is signing up for membership. The organization asks "who is your spouse?", "Who are your children/stepchildren?" and "Who are your emergency contacts?" New contact records are created, plus the appropriate "spouse of", "child of", "emergency contact of" relationships are created behind the scenes.
An existing member who is renewing his membership, may be newly married and will need to add his spouse. Or he may have a new child who should be added.
Allow the person filling out the form to specify complex relationships as needed, but common situations should be a default. For example: Many families consist of 2 adults married to each other, with all children in the family having those 2 adults as parents, and all the children are siblings to each other. This should be made as simple as possible to enter. Other complex situations should be supported as well, such as 2 adults living together each with children from a previous relationship, plus a child or 2 from the current relationship. Complex relationships may require more clicking than simple situations.