Donor Journey Sprint Day 1

Opublikowane
2014-04-07 11:18
Written by
jaapjansma - member of the CiviCRM community - view blog guidelines

The planning of this is an outcome of the unconference we had in Januari in London, with LLR, Amnesty Flanders, MAF Norway, Decaid Consulting and CiviCooP. The aim for this sprint, which last for only one week, is to create a trigger/action functionality for civicrm. E.g. we want a trigger that a donor becomes a member of a group of its total contributions are more than 25.000 euro's. Or when a contribution is completed we want to sent out a thank you message based on the communication preferences (e.g. e-mail, sms, postal mail).

What we have done today is to brainstorm on how we want to setup the extension for the trigger and actions. We have created a data structure and started working on the first draft of the user interface. In this blog I want to introduce and explain the data structure and the working of the triggers. 

Internal working

The internal working of the trigger action extension is based on three components:

  1. A trigger (e.g. amount of total completed contribution is more than 25.000 euros)
  2. An defined action (e.g. add contact to a  specific group)
  3. Trigger-Action definition. This is combining a trigger with an action and adding information on when to do the processing (e.g. every morning, always, weekly).

The Trigger-Action mechanism will be checked with a regular cron job. So that the triggers and actions can be delayed/processed at a specific time and so that they don't block the user interface.

Data structure

The data structure for the extension follows the internal working except that another tabel is added. So we and up with four tables

  1. civicrm_trigger_rule - the trigger (description of the entity e.g. contribution)
  2. civicrm_trigger_condition - the conditions for the triggers (e.g. sum of total amount of contributions, e.g. only contribution with status complete). Multiple conditions can be combined for a trigger
  3. civicrm_action_rule - the definition of what to do, which consist of the api parameters, api entity and api action. This way we make it possible to define every action which is possible through the api
  4. civicrm_trigger_action - linking of triggers and actions together with a schedule parameter

The data structure might change during the week so for a more actual description of the data structure see the documentation of the extension on GitHub: https://github.com/CiviCooP/org.civicoop.triggers/blob/master/docs/dataStructure.md

For developers: The trigger extension and its documentation can be found at https://github.com/CiviCooP/org.civicoop.triggers so if you want to contribute feel free to fork and do pull requests of this repo.

Comments

Seems like this is the starting point of workflow in CiviCRM. This definitely is needed across multiple parts of the system.

It has a fair bit of similarities with existing workflow engines. So if u'll are not familiar with rules and/or maestro and/or other CRM's might be worth spending some time reading on what they do and how they handle things, their schema etc (I'm assuming we can build something based on their past experience)

overall, definitely a great project and thanx for spearheading and pushing this forward

 

Yeah - sounds quite a lot like drupal rules - except rules gives you the option of listening to the post hook & acting immediately vs doing when cron runs (we've only ever done the former)

We did actually discuss the post hook :-) As we currently have funding for 1 week of work we decided to leave it for now, but it is definitely on the wish list too. We will propose the Donor Journey work for the after CiviCon London sprint to take it a little further.

Just thinking about it - key parts of drupal rules are conditional loading & complex conditional statements. So, for conditional loading it 'understands' in the UI that if you have a user id you could load a contact id & load their current employer & then you might have a condition on the employer.

 

It is fairly complex - & once you get into loops ie. does this contact have a membership of type y you actually wind up needing an extra module to support it. But the idea that starting from a contribution you can check a value on the relevant contact or soft credit contact when building a rule is powerful.

 

There are some screen shots in here - http://fuzion.co.nz/blogs/complex-civicrm-relationship-role-synchronisation-recipe but I am sure there are better rules resources if you want to see more on how drupal does it

Thanks for all the comments. Please add more if you would like to do so. But as Erik said we have funding for one week, so we try as much as possible to do in this week and we try to make it flexible as needed but we need something by the end of the week which is ready to be used. So rather to be too flexible and too abstract we are more working on a concrete level. However that doesn't mean that we don't think about it we do, but we won't implement it (yet).