What (recurring) Receipting options work for you?

We get a steady trickle of requests regarding changes to what receipts go out when someone signs up for a regular payment. We use an extension to help with this 'norecurreceipt'. The extension basically prevents the is_email_receipt from being set to ON on the civicrm_contribution_recur table - thus allowing the inital mail to go out but not the subsequent ones.

I discussed this some time ago with Dave & he suggested I post a blog to see where other people are at with recurring receipting.

What happens now?

The built in CiviCRM receipt workflow is that when someone signs up for a recurring contribution or membership they get

1) A notification that a recurring receipt has started
2) A notification that the an initial payment has been made
3) A notification of each payment that is made
4) A notification at the end of the timeframe.

You either get all or none.

What do people want?

We have different customers wanting different things - these are the requests we are hearing
1) We want them to get the start and end emails and no others
2) We want them to get a receipt each payment - but not the start-end date ones
3) We want them to get a receipt each time - but we don't want it to always be the one associated with the contribution page they signed up for because that was a specific campaign
4) We want one-off payments to get receipts but all communication with recurring payees will be highly customised

5) We want them to get only the first payment receipt (I think I remember that request correctly)

Possible approaches?

1) Site-wide setting to specify whether or not to send out start - end notifications.

Advantages

• easy, not much code or risk
• seems that core shouldn't be imposing an opinion on whether these should go out

Disadvantages

• yes, it's another setting in core
• not clear how hookable it would be for custom cases (or how much that matters

Scale - trivial

2) Write custom extension to abort mail going out when it's using the start end mail template using hook_civicrm_alterMailParams.

Write different extensions for the various other requests

Advantages

• this is probably what will wind up happening :-)
• No core code involved

Disadvantages

• This just feels hacky to me - having core force a set of assumptions & needing to install one or more extensions to counter them
• My reading of the code suggested activities might still be created
• The hook is called for every email in the system - so that could be a noticeable overhead for large civimails
• From reading the code it is possible the hook doesn't have enough information as yet (TBD)

Scale - minor

3) Adjust core such that if a workflow_template is disabled then it will skip sending that mail out without error

Advantages

•  all do-able within configuration and fairly easy to do and maintain, plus can apply to other templates

Disadvantages

• - could be confusing as to why things aren't going out if disabled.
• - might need a permission to allow them to be disabled

Scale minor

4) Allow per-contribution-page configuration of follow up workflow emails

-ie. the UI for contribution pages would have a select box for start, end, first and ongoing emails. If none set for an option then no email would go out.

Advantages

•  more configurable.
•  Feels more robust
•  existing recurring can be changed over time
• Provides format for linking other 'template items' to contribution page - e.g pay_later_text as a template, moving fields from membership block

Disadvantages

• more work
• could lead to templates not being set by over-sight
• what happens for back-office?

Scale - major.

Here is what civicrm_entity_msg_template might look like