At Amnesty International Vlaanderen we are starting a Petition Journey. The aim is to improve the engagement of people that sign a petition for the first time as their first point of contact with Amnesty. We then would like to send them an email with a survey immediately, and then for 5 weeks an email each week. One will be informing with a video link, one will be an invitation to register for an event in the same campaign, one will be to invite them to sign another petition etc.
We are using CiviCRM and specifically the CiviRules extension for this. We have configuration where our public website and CiviCRM are on different servers. We have a petition form on our website that sends data to CiviCRM automatically using CMRF.
For this specific Petition Journey (which we call Brave) we have set up a campaign and a group for the people that will be in the journey. Obviously anyone that opts out from any of our email campaigns should also no longer receive any Brave mails.
We have set up the following rules:
Rule number one - triggered by activity is added
-
the first rule catches any petition signed on the website, which comes into CiviCRM automatically as an activity of the type Petition Signed. The rule then checks if:
- the activity type is Petition Signed
- the activity status is Completed (it probably always will but just in case)
- the activity is in the campaign Brave
- the target contact of the activity is a Brave candidate (this is a condition developed specifically for Amnesty International Vlaanderen which checks if the contact has no contributions, no SEPA mandates, no memberships, no activities other this petition signed and has never been in the Brave group before (to avoid opt-outs getting back in). If you are interested you can find the source code here: https://github.com/CiviCooP/be.aivl.aivlrules)
- when all conditions are met, the contact signing the petition is added to the Brave group
- below is a screen print of this rule in a test environment
rule number two - triggered by contact is added to group
The second rule is triggered whenever a contact is added to a group (so actually straight after the first rule). This rule actually sends out all the mails if all conditions are met.
-
the rule checks:
- if the group the contact is added to is the Brave group
- if the contact is not deceased (just in case and to be sure!)
- if the contact is in the Brave group. This sounds a bit double initially as we already checked if the group is the Brave group. However, when the delayed mails are actually sent out 1, 2, 3, 4 or 5 weeks later the conditions are re-checked and if the contact was removed from the group in the mean time the mail will no longer be sent. This is important for opt-outs (check rule number three) but also allows us to intervene by removing a contact from the group manually whenever we think it is required.
- when all conditions are met, the first mail will be sent immediately, the second after 7 days, the third after 14 days, the fourth after 21 days and the fifth after 28 days
- below is a screen print of this rule in a test environment
third rule - triggered by a contact changed
The aim of the third rule is to make sure that when a contact tells us they longer want to receive stuff from us we do not send them mails from the Brave campaign.
- the rule is triggered when a contact changes
- the check is if the 'No Bulk Emails' for the contact has been checked
- if that is the case, the contact is removed from the Brave group
- below is a screen print of this rule in a test environment
