Donor Journey Sprint Day 2

2014-04-08 12:53
Written by

Yesterday I wrote a blog about the first day in the sprint for the donor journeys. I have discussed that we are focussing on a trigger/action extension to automate most of the donor journeys. I wrote a bit about the internal working and the data structure of this extension. 

Today we have finsished the internal working of the system. It is now possible to define triggers and actions. Right know you can enter those only in the database. We have made a start with the user interface and we continue to developer the user interface tomorrow. So that a user can enter a set of triggers and actions. In this blog post I want to show you how you can enter the trigger and actions in the database. The reason is that this will show in more depth how the extension works.

To explain how the extension work let me first explain which trigger/action I will use in this example.

Example: add every John to the group Johns

For every contact which first name is equal to John we want them to be added to the group 'Johns'. This group has id 6.

Trigger Rules

The trigger rules and the condition determine which entities to match for triggering

ID: 20

Label: When firstname = John

Name: firstname_john

Entity: Contact

Trigger conditions

ID: 30

Trigger rule id: 20

Field: first_name

Value: John


Aggregate function:

Grouping field:

Action rules

The action is the action which is executed on a found entity. The action consist of calling the civicrm api.

ID: 40

Label: Add contact to group John

Name: add_to_group_john

Entity: GroupContact

Action: Create

Parameters: group_id=6&contact_id={}

The API parameters can contain *tokens* which consist of curly brackets around them and the entity name with a dot for the field of the entity. e.g. {contribution.total_amount}

Trigger actions

A trigger/action pair is a combination of a selected trigger with a selected action.

ID: 50

Trigger rule ID: 20

Action rule ID: 40

Schedule: Tomorrow

Is active: 1

Start date:

End date:

The schedule parameter is a php relative date format see for this fornat specification.


The extension for the triggers has two hooks

  • hook_civicrm_trigger_condition_parse This hook is used for parsing condition and adding where and having clause an entity DAO. E.g. a where clause to match contributions for this trigger
  • hook_civicrm_trigger_action_parse_params Every action results in an api call and with this hook you can pass parameters additional parameters to the call

See for more detailed description of the hooks


When you mention triggers, are you referring to a new type of record/data that is managed by your extension? Or are you using MySQL triggers?   If not one in the same, then the choice of words is confusing to me. 

Hey Sarah,

I mean triggers in the broad sense of the word. Meaning something triggers an action. This doesn't have anything to do with triggers on database level. 

If you are confused by the word tirgger why didn't you ask mysql to change their name? ;-)