Skip to end of metadata
Go to start of metadata

There are some really great suggestions for scenarios listed here. But I think that a lot of these are things that are still a bit down the road. What is most important right now is integration. Currently there are some usable modules for handling contacts, web users, volunteers and donations. But the problem is that these modules don't really work together.

I can see how the volunteering and contact management are starting to come together, but there also needs to be strong ties to web access control and donating. The user table for the website should not be separate from the contacts table because access needs to be defined based on what groups the contact is a part of.

Another key for small organizations is integration with donations. There are some organizations that because I have donated twice to their organization I am considered to be two different people. This is a major issue for small organizations that can't afford to be sending mailouts to the same person twice.

These organizations also need to pinpoint who are the people that are consistently involved both from a volunteer perspective and a donation perspective.

One key to this is managing the creation of duplicate members. As I start to think about this I'm starting to realize how big of a can of worms that is. In one scenario a person may donate and then later volunteer on a project. It's going to be difficult coming up with rules to determine how much similarity in information is enough for a match. The user can then be prompted "Your information is similar to someone we already have on record. Have you donated to us in the past?". A more difficult scenario is matching of household data. It becomes a privacy issue if you just say "Bill Smith has the same phone number as you, do you live with him?". But perhaps if they have the same last name it's ok to prompt that.

I'm really excited about where this project is going though. It has the potential of being, how shall we say, the epicentre of a major earthquake. Kudos to everyone involved.

Labels:
  1. Jun 16, 2005

    Thanks for the kind words.

    I don't think technology is going to solve the problem of "dirty" data. We have code that checks for duplicates when creating a CRM record, so we're taking the first step to addressing this issue.

    But the real solution will always be organizations investing human time into looking for duplicates, resolving issues, etc.

    I think you don't rely on users to do the duplicate decisions for you. I think you provide tools to administrators to identify potential duplicates, make decisions, and merge records if necessary.

  2. Jun 20, 2005

    Dave...
    Regarding integration of user table and contacts table - we have implemented "User Sharing" functionality - based on the model that any 'people info' other than the core user fields of user_name, email and password should be stored in the CiviCRM contacts tables. We then give sites the ability to configure which contact data fields should be 'exposed' to the end-user during sign-up/account editing/profile viewing. The spec is here:

    http://objectledge.org/confluence/display/CRM/CiviCRM+User+Sharing+and+Drupal+Profile

    And you can play with the configuration admin a bit in the sandbox: http://sandbox.openngo.org/civicrm/drupal-php5/civicrm/admin/uf/group?reset=1

    We will be addressing the issue of de-duping more deeply in our 1.1 release. And our Donations functionality (which we are beginning active development on next week) will be tightly integrated w/ the contacts tables. Stay tuned to our crm-dev mailing list for draft specs, etc.


Creative Commons License
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-Share Alike 3.0 United States Licence.