Since CRM stands for Constituent Relationship Management, one would expect to have robust capabilies for dealing with relationships. This expectation is met when using the staff areas of CiviCRM.
However, in any of the self-service areas such as event registration profiles, membership profiles, and stand-alone profiles then relationships are missing. Each profile can only be used to collect information about a single contact.
This lack of support for relationships causes headaches in the following situations:
- An organization has an intake form for new clients, where they need to get emergancy contact information, and spouse information. They would like to use the relationships "Emergancy Contact of" and "Spouse of"
- An organization has an application form for someone applying to be a volunteer. They need to collect 3 personal references for this person. They would like to use the relationship "Personal reference of" to link the 3 new contacts to the volunteer who is filling in the form.
- An organization offers many programs and events for children and teenagers. They need to collect the child/teenager's information, plus information for both parents, and information for their emergancy contacts. They would like to use the relationships "parent of", and "emergancy contact of"
- An organization is hosting a gala dinner. Most of the participants are bringing their spouse/significant other. In many cases, the spouse is already in the system. They would like to use the "spouse of" relationship. Also they would like to streamline registering for events for someone who is signed in, and is bringing their spouse to an event.
I have started documenting and planning how to address these issues on the wiki at: http://wiki.civicrm.org/confluence/display/CRM/Relationship+improvements+for+the+self-service+areas. Please comment on or add your thoughts to the wiki document. Hopefully the final approach will cover all the different ways people use relationships.
In the past, some people have suggested writing a hook or custom templates to handle these requirements. But this approach is very rigid in that it requires a programmer to create relationship-aware profiles/forms. This results in a very brittle workflow for the organization because the office administrator, who is non-technical yet can normally create CiviCRM profiles as needed now has to rely on a programmer to change many profile forms.
It also means smaller nonprofits using CiviCRM have to incur the expense of a programmer for many situations, for features that they expected to work out of the box.