Aller directement à la fin des métadonnées
Aller au début des métadonnées
Deprecated page

This wiki page is no longer kept up to date with the project progress. Up to date documentation on CiviRules can be found at

This page is work in progress documentation for CiviRules. 

Table of contents


CiviRules is based on the Drupal Rules module and does react on an event (post create contribution) and executes a certain action when certain conditions are met. 

This page will contain what we have thought of what needs to be done to develop such an extension. Rather than just starting (what we have done with trigger-action extension) this one is a bit more thought of. So this description is also a basic for a wider debate on how things should work.


  • The action should be basically API actions
  • Should be flexible to extend by developers. E.g. it should be easy to add new event types, new condition types, new action types
  • Rules (event, condition and condition) should be stored in the database as well as in code, like Drupal Views and Drupal Rules but does not need to be as sophisticated as Drupal does.
  • It should be possible to extend the storage layer
  • It should use the queue mechanism of CiviCRM Core (take a look at scheduled reminders on how to use this queue mechanism)
  • It should be possible to send e-mail, sms, print pdf letter as an action


The following needs to be done. This are the actions we identified so far

  • Create mockups

  • Investigate the core queue mechanism and document it

  • Create the basic framework for the rules extension

  • Create a UI around the framework

  • (API) action for sending e-mail

  • (API) action for sending SMS

  • (API) action for printing PDF Letter


In this section several mockups show the desired workflow of a couple of CiviRules.

Initial form from Administer Menu

Initial form shown to user when he/she selects 'CiviRules' from 'Administration' menu

Manage CiviRule Form

Form shown when a user clicked 'manage' on the initial form or clicked on 'Add CiviRule'. In the latter case there will obviously be no existing Events, Conditions or Actions.

Add Event Form

The following form will be shown when the user clicked 'Add event' in the Manage CiviRule form


Add Condition Form

If the user clicks 'Add condition' in the Manage CiviRule form a couple of forms can be presented, depending on what route is followed. The first form will always appear, the others depend on the selection. A couple of tracks are added here without the presumption of being complete

Data comparison form

If the user selected Data comparison and clicked 'Continue'

Data value form

If the user typed Contact.total_contributed_amount_this_year and then Clcked 'Continue':


That completes this specific condition, the next step would be to add the action.

Add Action Form

So if the user clicked 'Add action' in the form Manage CiviRule, the following sequence will start:

Add contact to group form

In the example 'Add contact to group' has been selected so the next form will show a list of active groups that can be selected, which then completes the action.

Set data value form sequence

If the user selects 'set data value' he or she will be presented with the next form. Actually, most actions could be done with 'set data value' (or a combination of them) but some shortcuts will be provided with the data selectors.


In the next form the user gets to enter the actual value. This could be an input field (with relevant replacement patterns if any) or a select list.

Send PDF letter form


Below a draft of the API for the framework. The framework consists of the following

  • Interfaces
  • Hooks
  • API


Below a more detailed description of the interfaces we are going to use in the framework. The interfaces we have identified are:

  • event definition
  • action definition

Event definition

The event definition contains a system name (name), a human readable name (label) and a description. Any new event should implements this event definition.

Action Definition

The action definition interface consists of  a system name of the action, a human readable label of the action and optional an entity on which the action is performed. An action could be something like add contact to group, or set data value.



The following hooks are available from this extension. So that you can customize this extension to some extent.

  • hook_civicrm_rules_event_definition
  • hook_civicrm_rules_alter_dataselectors
  • hook_civicrm_rules_action_definition


This hooks returns an array with definitions for events. An event definition could be for example e.g. a post event or a pre event. An event definition is defined in a class which implements the CRM_Rules_Interface_EventDefinition

Below is an example usage of this hook


This hooks returns an array with definitions for actions. An action could be something like send e-mail or set data value. Every action is an object which implements the CRM_Rules_Interface_ActionDefinition

Below is an example usage of this hook


This hook can be used to alter available data selectors within a replacement pattern. This can be useful to add a data selector for total_contribution_amount_this_year at contact level.

Below is an example implementation of this hook.

API: InvokeEvent

The API of this extension consist of a call to the extension to trigger events of a certain type. E.g. in the post hook we want trigger the post event for a certain object. 

This call will invoke the rules extension to check whether any post events should be checked. Our aim is to implement by default the pre and the post events which are triggered in the pre and post hook and we will use a flexible mechanism because if any new use cases appear in the feature they can be easily implemented. However we cannot think of any yet.

As soon as invoke event is fired the rules module will check whether any active events are available and executes those events.


The invoke event has the following parameters:

  • event: the name of the event
  • event_parameters: an array with additional parameters for this specific event


The extension uses the follownig models:

  • CRM_Rules_Model_Rule
  • CRM_Rules_Model_ReplacementPattern

Model: CRM_Rules_Model_Rule

The CRM_Rules_Model_Rule holds all the data belonging to a rule, which is the event, the conditions and the actions. Also when an action is scheduled to be executed with an offset the replacement patterns should be working in the future. We don't know yet how to achieve this. 

Model: CRM_Rules_Model_ReplacementPattern

Data diagram

  • Aucun
  1. Oct 01, 2014

    Tim Otten dit :

    A few thoughts in no particular order:

    • There's a mockup for "Manage CiviRule Form" and some more mockups for "Add Action Form", etc. I'd vote for putting these all on the same page – but possibly using modal dialogs, edit-in-place, or something else. Making these separate pages (which, IIRC, is how Drupal does it) makes it harder to keep track of where you are / what you're doing.
    • Implementing an API for "Rules.InvokeEvent" seems cool – like a third-party system could trigger events over REST or CLI (drush/wp-cli/etc). However, I think there should also be an internal/OO interface for triggering events. The concern is performance – if hook_civicrm_post is going to call InvokeEvent for every data update, then we don't want the overhead of civicrm_api(); we want something a thinner / more specialized.
    • There's some conceptual similarity between "data selectors", "mail-merge tokens", and (in the v5.0 discussion) conditional fields. Not sure if there's any action item or coordination issue, but I want to throw it out there.
    • The idea of an "action" which is  a loop sounds curious – what would be an example?
    • hook_civicrm_rules_action_definition - The current description has the hook returning array of definitions. You don't see this very much in Civi's hook system – instead, it tends to use the "alter" pattern (e.g. "function hook_foo(&$action_definitions)"). IIRC, we've found that pattern to be more reliable in different hook systems (Drupal hooks / Joomla events / etc)
  2. Oct 01, 2014

    Awesome stuff! Can't wait to begin using it. This will revolutionise CiviCRM. 

  3. Oct 01, 2014

    obowden dit :

    This is a bit of a brain dump which I'll think about but wanted to get down in case I forget.

    • How would this handle things not happening which we'd want to trigger off. For example, a donor doesn't respond to a mailing/email etc.. we could send a follow up after X days.
    • Contributions should handle soft credit totals too.
  4. Oct 14, 2014

    Jon Goldberg dit :

    This looks very cool!  I'll note that in your "special conditions" section - two of the conditions are handled by the "Summary Fields" extension, and the last condition ("Has a Birthday") shouldn't be special (date_of_birth IS NOT NULL).  So maybe there's no need to build those out right now?

Creative Commons License
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-Share Alike 3.0 United States Licence.