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.
Comments
1. Might want to check the latest webform + civicrm v2: http://drupal.org/project/webform_civicrm
It has support for multiple contact creation and relationships between the contacts created. Kudos to colemanw for pioneering and pushing this forward. Yes, this is Drupal-specific, but it is similar to the views integration and takes the profile concept to the next level in a very nice manner without a lot of code duplication, IMO
2. Am a bit stumped on the comment:
"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."
Not sure how/where/why/when those expectations were set and by whom? I dont think any docs say that this happens out of the box. I do think both small and large non-profit orgs are part of the ecosystem and need to help stregthen and build the ecosystem in addition to just "expecting things to work for them"
lobo
In the wiki document, I mention using WebForm as a possible solution. An enhancement would be needed as currently WebForms cannot be used as part of a event/membership registration. Per Colman's documentation: " cannot be used to replace contribution, membership, or event registration forms"
I was too dramatic on the comment "that they expected to work out of the box." These relationship features are not documented anywhere, so no one expects them. However, the relationship limitations in the self-service areas do mean that a technical resource/programmer is often needed to accomplish the mentioned scenarios.
Many nonprofits do not mind contributing code/patches/improvements to strengthen the CiviCRM ecosystem. What they do mind is that after the code is written, that their non-technical office administrators can not be independant in their day-to-day work.
I don't think you were too dramatic. People don't read every bit of documentation about a piece of software before they start to have expectations of what it can do. And if their expectations are wrong, it's not necessarily because they have unreasonable expectations. It might well be that the software is simply not doing seemingly obvious things. I would put this in that category. That doesn't mean that it's the software's (or programmer's) "fault" either. But the programmer should definitely pay attention when people say, "How come I can't ...bla bla blah? I assumed, given what I *had* read, that I would be able to do that."
After reading all about the capabilities CiviCRM has regarding relationships, I was *very* startled to discover that I couldn't do a *seemingly* simple (and clearly connected) thing like have a mother register with her children for an event (out of the box). So I don't think it's too dramatic to say that people will expect it out of the box. All of those features for relationships in the backend are awesome, but it is quite surprising that they don't carry over to the front end where the data-collection often takes place.
So you can count my vote in on this idea, for sure. I'll go take a look at the wiki and see if I can help out at all in brainstorming.
I dont think anyone will disagree that these are great enhacements for CiviCRM and definitely needed. Over the past few years this has come up repeatedly on the forums and we've made progress in various directions (w/o hacking core) to allow it to happen from a few years ago (hooks, webform etc). I had this need for the school stuff, and did it via hooks (not great, but allowed me to use civi in a nice non-hackish manner).
However as with everything open source, for something to actually get coded, someone needs to either do the work and/or sponsor the work that is needed to be done. Very recently, someone wanted the ability to view/edit contact + activity profiles which we did and made available as part of 3.4.x. We also ensured that it would be a bit easier to generalize if/when someone decides to add other object support to it.
If I had to guess, a generalized solution for covering most objects (activities, contributions, participant, membership) with create/edit/view is probably at a minimum a 100-150 hour project. We'd be happy to work on it and get it into core for a future release (or coordinate wth some other developers who are willing to do the work)
lobo
And just so you know, I do think the company I work for would put its money where my mouth is if this gets to the stage of being a MIH. :) It's good to know up front what you think it would take in terms of hours. It's definitely a serious project.
In general for such large initiatives, we prefer to have a couple of seed sponsors (i.e. companies willing to put 25-100% of the total amount). Any chance your company would be willing to do so. The consulting contract and rates are on the wiki here: http://wiki.civicrm.org/confluence/display/CRM/Consulting+Services+Agreement
While we do estimate 5,000+ orgs using CiviCRM, only a very tiny fraction of them actually contribute back via money / code / docs etc. hence the need for seed sponsors :(. Based on the past 4 MIH experiences, MIH's with seed sponsors are the most likely to achieve their fundraising goals
Finally thanx for willing to put your money where your mouth is :) In the meantime, you should get your company to support the current set of MIH's for 4.1: http://civicrm.org/mih
lobo
Here's another common use case: http://forum.civicrm.org/index.php/topic,19368.msg85009.html#msg85009
Webform-Civi 2 is shaping up nicely, and I'm excited about the new relationship additions. I'm not sure if that module will include event/member registration as a feature in the future. The basics of that should be straightforward, but I'm not sure how it would work in terms of taking payments and working with price sets, that sounds kind of complex.
Meanwhile, the CiviRelate module seems like a good start toward making relationships from core civi profiles. You may want to check out/support that project.
Colman - I added the CiviRelate module to the wiki document as another possible approach. Your work on the WebForms integration is fantastic. I am still trying to get a sense of which approach would be the most logical starting point. What would the challenges be in integrating WebForms with payments and price sets?
Thanks for the endorsement of CiviRelate. I created it to scratch this itch in a particular project - applicants submitting references - and then generalized it into a full module in response to forum reaction. It would be great to see it as a core function though if we are to remain multiplatform since it's a Drupal only solution.
I would think that extending the contact reference field type to allow relationships to be built off (as CiviRelate does ) it wouldn't be too difficult (& useful).
You'd need to be able to specify the relationship type & permissions when you create the field
I also just wanted to give a cheer to Lobo's "related contact" option in the advanced search, which I have been using constantly since he added it, to send messages to parents of our students.