Our organization has been using (and loving) CiviCRM for almost a year now, but we initially had issues getting the membership history to easily capture the full range of detail needed. Our members often lapse from year to year, and because Civi’s natural process is to renew a single membership record instead of creating multiple, this caused us some problems. When discussing our experience and solution at various events, we found there was a lot of interest, so the purpose of this blog post is to discuss them in further detail with those who might find it useful to use our solution for their needs, and facilitate conversation towards sharing the solution with them.
Example: An Often Lapsed Member
Our organization offers yearly memberships, and a common sight in our records would be a member like “Jane Member”. Jane bought a 2007 Student membership, as well as one in 2009 and 2010. She also bought a Professional membership in 2012 and 2014. Civi’s base solution would capture this in a single membership record like so:
Member Since: 1/1/2007
Membership Type: Professional
Start Date: 1/1/2014
End Date: 12/31/2014
(5 associated member dues Contributions)
This angle had a number of limitations:
- Membership lapses were difficult to track and report on. One could theoretically use Activity entries to recreate these lapses, but the process was programatically complicated, especially in edge cases such as membership cancellations. This made reports involving yearly fluctuations in membership more difficult for staff than it needed to be.
- Membership type changes over the years were also difficult to track.
- Contributions did not have hard references to the memberships they were paying for. Again, a human could eventually manually figure it out, but it required an effort to reconcile multiple screens in the application. Programatically it was made difficult by the fact that one can pay for memberships in advance, so there was not necessarily a correlation between payment date and membership date.
- One could not track custom data per membership period. One overall membership record meant one instance of the custom fields, instead of one set per membership purchased. Ultimately, this meant that membership custom data was basically contact custom data, as they were both one-to-one, and the only outlet for custom data that was one-per-membership was by including it in the contribution. And we did not always have a contribution, as sometimes memberships were complimentary.
Our Solution: One Membership Record Per Membership
To get back to “Jane Member”, here’s how our solution would look – 5 memberships:
1. Start Date: 1/1/2007, End Date: 12/31/2007 (1 associated member dues Contribution)
2. Start Date: 1/1/2009, End Date: 12/31/2009 (1 associated member dues Contribution)
3. Start Date: 1/1/2010, End Date: 12/31/2010 (1 associated member dues Contribution)
4. Start Date: 1/1/2012, End Date: 12/31/2012 (1 associated member dues Contribution)
5. Start Date: 1/1/2014, End Date: 12/31/2014 (1 associated member dues Contribution)
You may notice that there’s no “Member Since” tracked here.. since that data technically only exists once for a Contact, we simply moved it into a custom field there. The existing “Member Since” field is disregarded.
This addresses our four problems:
- Membership lapses are tracked in one place, making reporting by staff easier. Now reports such as “Show me who has been a member at least 3 of the last 5 years”, or past timeframe searches such as “Show me who was a member in 2011 but not 2012” much easier.
- Membership type changes are easily tracked by year, helping searches such as “Show me who was Member Type A in 2012, but changed to Member Type B in 2013”.
- Each contribution is tied directly to its membership, removing the guessing game if contributions are bought in timeframes other than those they are valid.
- Each record gets its own instance of custom data per year, instead of having to share a single membership record.
What Changes Were Needed?
Luckily, the existing database structure was accommodating, but certain rules needed adjusting.
- Online registration needed to be adjusted to create a new record instead of renewing an existing one
- The concept of an “Upcoming” membership that was separate from the this year’s membership had to be added to the Member Status logic, and addressed in the membership status update job
- Certain queries needed optimization to return far fewer results based on the assumptions of the new structure
Potential Limitations
Our business model only requires one membership at a time. We do not depend on previous or existing memberships to process any logic (such as special pricing on renewals). Logic such as this may require additional functionality.
How Can I Use This For My Site?
We’re certainly interested in sharing our results with the community, and this blog is a means to figure out the best way to do so. We’d like to both gauge interest, and receive contact from people who are interested in using this solution. Currently, the code is composed of individual file changes, and is not slated to go into a core release. Our initial thought is to package it into an extension, if people are interested in facilitating it. Please feel free to comment, or contact me at rwilliams@aarweb.org.
| Attachment | Size |
|---|---|
 CiviVSAAR.jpg | 79.04 KB |