Overview
To increase the efficiency of your team working through set workflows, you may wish to add automation to your CiviPlus processes.
CiviRules is an automation tool, accessible to administrators, that allows the setting up of tasks or actions that the system will run automatically, when triggered by specific conditions. This is very useful for the automation of tasks that should always happen under certain conditions.
Each CiviRule has three components, described in more detail within the article
Trigger: “What event starts the rule — like when a contact is created or a contribution is made.”
Condition(s): “Checks that must be true for the rule to continue — like contact type is ‘Individual’.”
Action(s): “What happens if the conditions are met — like send an email or update a field.”
A very important cautionary note: with great power comes great responsibility!
CiviRules is an extremely flexible and very useful, but very powerful tool. Without extra care, or by leaving a rule you are working on setting up 'unfinished', you run the risk of creating a problematic automation that runs unsupervised in the background on your site.
Remember, CiviRules run:
⚠ All the time
⚠ Unsupervised
⚠ For all contacts/data
…a small mistake (for example, not including a 'condition' for your rule) can cause major issues, such as -
Sending large volumes of unintended emails
Updating and overwrite valuable data
Jamming/ slowing the site with thousands of tasks
To avoid accidental problems treat CiviRules with care and follow the "Golden Rules" at the end of this article
How to use CiviRules
Examples will help to illustrate how CiviRules could be useful for your workflows.
Example 1
I would like a contact who is the subject of a 'Prospecting' Case Type record to be added to a group called 'Warm Leads' when a staff member adds the 'Introduction Call Held' activity (assigned to the contact) to the case record.
Trigger: Case Activity is Added
Trigger for: Activity Assignees
Conditions:
Activity Type is 'Introduction Call Held'
Case Type is Prospecting
Action: Add contact to Group: Warm Leads
Example 2
I would like to assign a specific staff member the role of Case Manager every time a 'Prospecting' Case Type record is created.
Trigger: Case Created
Condition: Case type is Prospecting
Action: Assign Role: Case Manager *Name of staff member*
Example 3
When a Prospecting Case Type record has the Status 'Request Company Details', I would like a particular message template to be sent to the contact, with a link to a webform.
Trigger: Case Status is 'Request Company Details'
Condition: Case Type is Prospecting
Action: Send email to .... pick template
How to build a CiviRule
Here are the steps required to create a CiviRule for your Sales Opportunity workflow:
Step 1
Navigate to Administer --> CiviRules --> Manage Rules
Select Add Rule
Step 2
Populate the Rule Details:
Name: Internal title of the rule
Description: A brief internal description of the rule
CiviRule Tag(s): Rules can be categorised and sorted using tags
Helptext with purpose of rule: Further internal details of the rule
Enabled: Set whether the rule is active or inactive whilst being created
We recommend unticking this until you are ready to test the completed rule
Step 3
Create the Trigger:
Select a trigger for the rule from the drop-down menu and select Next
Choosing some triggers will take you to a secondary screen to allow you to add further detail to the trigger
Step 4
Conditions are often essential for narrowing down the triggering of the rule to the desired specific use case.
For instance, in Example 1, if no condition was used, the rule would trigger for every activity type and case type in the system.
Create the Condition(s):
Select Add Condition
(The options available for conditions will vary depending on the initial trigger chosen)
Once a condition is chosen, there is usually a further details screen where the specific options can be selected
Multiple conditions can be added to one CiviRule. This is particularly useful if your CiviPlus site has multiple workstreams, and you need to be very specific in your rules.
Step 5
Create the Action(s):
Select Add Action
Select an action from the drop-down menu
There will be a follow-up secondary screen too in most cases, to provide further details
Add a delay if applicable
Here you can add a time period by which to delay the action after the rule has been triggered.This can be useful to:
Introduce a gap between trigger and action (if other actions need to happen in this time)
Standardise when actions occur (e.g. invoices always go out at a set time on a set day)
Use rules to create future events (e.g create an activity, but 1 week in the future)
Useful Triggers for Sales Opportunity Workflows
Trigger | Uses |
Case activity Date is reached | Good for triggering alerts (internally or externally) that an activity is (or will soon be) overdue |
Case activity is added | Useful for linking rules to other areas of the system |
Case is changed | Useful for creating automation around caseflow processes |
Tag is added | This can be used to allow users to use tags as a shortcut to trigger rules or changes |
Useful Actions for Sales Opportunity Workflows
Action | Uses |
Add Contact to a group | Really useful for helping maintain mailing lists, or highlighting and reviewing contacts that have met certain conditions |
Add Tag to contact | Ideal for rules that are meant to help flagging to users (e.g. staff), contacts that have met certain conditions (e.g. had a meeting) |
Add (Case) Activity to a contact | Great for creating a more visible, easier to report on record on the contact of a specific thing happening |
Send Email | The most commonly used action |
Send Email to related contact | Useful for alerts and often case processes
|
Set Custom field on contact | Can be used to help keep data on contacts up to date based on their other interactions in the system |
Show a message to CiviCRM Users | Good for internal (staff-facing) alerts for users |
🚨 Golden Rules for using CiviRules
We strongly recommend always following the guidance below when using CiviRules to make sure they work correctly, and don’t cause problems:
1. Always work with a rule set to “Disabled”
2. Always double check the logic and conditions before enabling
3. If possible, run a test version of the rule before deploying a main version.
1. Always work with a rule set to “Disabled”
When creating a rule, make sure it is not set as enabled, and if in doubt, leave a rule as disabled while working on it to find the right configuration
2. Always double check the logic and conditions before enabling
Is the trigger the correct one? Some of the triggers can look similar
Is there a condition in place? It’s easy to leave this step off and can cause enormous problems!
E.g. This rule will send an email for every single activity of any type!
3. If possible, run a test version of the rule before deploying a main version.
For example, let’s say we’re configuring an email alert to be sent to “admin@client.com” whenever someone adds a “review meeting” activity.
We know that this is a regularly used activity type, which multiple staff members are adding each day.
The final version of the rule might look something like this:
However, before I set the above, I would do the following:
a. Create a new activity type called “Test Activity Type”
b. Set the CiviRule to use this test type (that nobody else is using)
c. Add an activity to a test contact, to make sure that the CiviRule is functioning correctly in a controlled context. If it runs normally, I can change the settings to use the “Review meeting” activity as planned.
Note: How to test a CiviRule is up to you, and will depend on what the rule does, but it always pays to consider if there is a “test” version of the workflow you can use before going live.