Organisational membership renewals - best practice

[Upperholme]

CiviCRM provides a great facility to allow an individual to sign up their organisation as a member. But there doesn't seem to be any comparable approach when it comes to renewing that membership.

I assume that any scheduled reminders about membership renewal will be sent to the email address on the organisation contact record. In many cases this might be a generic email address of the type info@example.org.

If we make use of the facility to enable an individual to sign up their organisation as a member, would it not then be sensible to assign to that individual a unique relationship - something like 'primary membership contact' - with the organisation record, and then enable the scheduled reminder to be sent to them rather than the organisation contact.

I've used a Drupal webform to get some of this working, so I can create the relationship at sign-up and have the individual in a group of primary member contacts, but I can't see how to make use of the Scheduled reminder, without copying the individual's contact email address into the contact record for the organisation. Clunky.

Wondering if anyone has this cracked? Or has a different approach to facilitating organisational membership renewals? It does seem like something of gap in CiviCRM's otherwise sleek loveliness.

[petednz]

I think this is still a tricky one. And happy to put some thought/time in to a workable solution. Currently our major use case is using Fixed Term - fortunately - so we pull together the group of Primary Contacts - and fire the reminder to them, since the checksum 'has' to go to an individual, not an organisation.

The only thoughts i have had about making this automatable is to have a special relationship of 'primary contact' created. It should imo be set to have a default limit of 1. And someway of flagging any member organisations that do not have one.

(or maybe it could be another 'checkbox' on current employer?)

Joining 'on behalf' of an organisation should therefore create the above - and then Scheduled Reminders for 'on behalf of' Organisation memberships' should go to the Primary Contact.

To be honest, other clients who use this much we have tended to persuade them to make their Org. Memberships 'fixed' rather than Rolling, just to make this manageable.

[petednz]

While I have this back on the table

So what if we had an "on behalf of (OBO) memberships' extension that did the following (with no idea how easy/hard I am making this)

When 'on behalf of membership' is created

- Current Employee relationship is set to 'permissioned' (since this is required for renewing)

either

- Current Employee has another field that sets as 'primary contact' and which only permits 1 per organisation (editable in code if this has to be overwritten)

or

- additional Relationship of type OBO Primary is created, set to Permissioned (though that is kind of redundant since 'employee of' needs to be this)

- OBO Primary is limited to 1 Active per Organisation

then

Scheduled Reminders for OBO Memberships

- automatically get set to the OBO Primary contact (where one exists) and to the Org'n where one doesn't

[CiviTeacher.com]

In my experience the following is already true as of 4.2 unless something has reverted.

1. when signing up "on behalf" of an org for membership a permissioned employee/er relatioship is created with an individual

2. when the auto-reminder renewals are sent, those reminders are sent to:
   a. the organization contact itself (if it has an email) such as info@myorg.org
   b. the permissioned employee contact such as jane@myorg.org that orginally filled out the form
   c. any OTHER contact since added as also having a permissioned employee relationship with the org such as rob@myorg.org and pam@myorg.org

3. the auto-renewal reminders are NOT sent to employees withOUT permissioned relationships or any other relationship with that org

Not sure why you are creating a Drupal Webform, but that is not required unless you wish to build more than one permissioned employee relationship on the first signup.

[Upperholme]

Hi CiviTeacher
This is very interesting information. I've not come across any of this in the documentation, maybe I've missed it. I had heard that in the case of an organisation being the member, then individuals with permissioned relationhips get reminders, but never seen any evidence that this was in fact true. A well kept CiviCRM secret? What's your mileage on this one petednz?

[petednz]

Mileage? None - and no that isn't a poor joke about metric system

I have a client who is testing this and will report back on their behalf (since I am permissioned - and yes that is a bad joke).

Thanks for your post Stoob

[CiviTeacher.com]

Upper holm testing is a fun way to find out if it's true and only takes a few minutes.  Create the reminder BEFORE you creat the memberships for the contacts.

[Upperholme]

I'm not sure I'd class it as fun, but I'm certainly testing this out.

I'm really curious to find out how you found out about this functionality. Just by testing to see what happens, or maybe you wrote the code?

So this has been in place since 4.2, yet there is no mention of this functionality in the documentation. I'm reminded of the quote "If a tree falls in a forest and no one is around to hear it, does it make a sound?". If a feature exists in the software, but no-one knows about it, does it exist?

And it also begs the question: What other 'hidden' functionality might already be in place in CiviCRM?

[Upperholme]

Test result so far (using CiviCRM 4.5beta9):

As advised, once I have the membership type set up, I then create the reminder before creating the memberships. The reminder settings give me no options as to who might receive the reminder (other than selecting a group, which is not relevant here).

I then create the membership as an anonymous user signing up through a contribution page that I've configured to force 'on behalf of' behaviour.

I've set the install to dump all mail into mail.log

I see that the receipt/confirmation email for the membership is sent to the email address given for the organisation contact, and copied to the permissioned individual who signed up, which is nice.

But the reminder that I've set up is only being sent to the organisation contact.

Maybe I'm missing a config setting, but I've had a good look round and can't see anything obvious.

As I say this is using 4.5beta9, so it may vary with 4.4 (which I'll take a look at next). If this did work out of the box it would be great, and eminently sensible. I'll update when, as and if I find out more.

Update: just did a clean install with D7 and CiviCRM 4.4.7 and tested again. As before the confirmation/receipt gets sent to both the org email address and the individual who signed up, but the reminder is just going to the org address.

[CiviTeacher.com]

Ok. Well that's not the results of my testing last year.  Perhaps the code has changed or your test was incorrect.  File a bug?  Hire a developer?

[Upperholme]

Any idea what version you successfully tested on? 4.2?

Have you used the feature on a production site? Your notes read as really quite specific. Any more information you can give would be most welcome.

As it's not a documented feature I don't think we can realistically class it as a bug, but before I think about investing in development it would great to know more about your experience/use of the facility.

[Upperholme]

Huniting on the issue tracker I've found https://issues.civicrm.org/jira/browse/CRM-11342 and judging by petednz's earlier comment Civiteacher.com == Stoob, so clearly at some point this was operational. Progress.

That issue states that the reminder only goes to the permissioned individual/s as at version 4.2.7.

Based on that I think we have grounds for reporting a bug and getting this feature back on the road.

[Donald Lobo]

stoob:

would be great if you can test it on 4.5.x since u know that fucntionality fairly well

if this is not working, please comment on the original issue and we'll reopen and schedule it for a future release

Would be even better if we can capture the behavior as  a webtest (and/or a set of unit tests) to ensure we dont break this again

lobo