| Table of Contents |
|---|
...
A Conditional Alert is similar to a Broadcast in that you are sending content to recipient(s) on a specific schedule. The main difference is that for broadcasts the system only ever creates one instance of the schedule you define, and with conditional alerts the system creates an instance of the schedule for each open case that matches the given rule criteria. Conditional Alerts are designed to create an instance of the schedule you define every time the rule's criteria go from being False to being True for an open case. That could mean that the rule is being run for the first time and it matches a case, or it can mean that a case which didn't match the rule before is later updated to match it.
To understand how Conditional Alerts respond to case changes, consider the following example. Suppose your project has 3 cases, all with case type "person", and you track a "status" case property which can either be "green" or "red". These are the 3 cases in your project:
...
With these three cases existing in your project, suppose you now create a Conditional Alert which will send an Immediate SMS to Mobile Worker Bob for each "person" case with "status" equal to "red". As soon as you save the Conditional Alert, the rule will run against all "person" cases in your project and for each one that is in "red" status, it will create an instance of the schedule (which in this case is an immediate SMS) to be sent to Mobile Worker Bob. Put simply, it will send 2 SMS to Bob - one in response to Joe being in red status and one in response to Jaime being in red status. From here on out, you do not need to resave the Conditional Alert to send new SMS - the system will automatically keep the rule up to date with changes made to your cases. If you do save the Conditional Alert again but don't make any changes, no new SMS are sent because nothing changed.
Now suppose a new case is created so that you now have 4 cases in your project:
...
When the case for Oscar is created, a new SMS will be sent to Bob in response to Oscar being in red status. No other SMS will be sent because no other cases were created or changed.
Now suppose Monica is updated to be in red status as well, so that now the 4 cases in your project look like this:
...
When Monica's case is updated, a new SMS will be sent to Bob in response to Monica being in red status because the rule went from being False to being True for her case. No other SMS will be sent because no other cases have been created or changed.
Now suppose Joe's case is updated, but his status is not changed - it's still red. In this situation, no new SMS will be sent because the rule was already True for Joe, and the schedule is only initiated when the rule goes from being False to being True.
...
Case Property (optional)
First, enter a type the name of the case property name to match, and then . Then select the different match types can befrom the following options:
| Match Type | Description |
|---|---|
| equals | The case property must exist and must equal the given value. Do not add quotes to the value you enter. |
| does not equal | The opposite of "equals". So, if the case property does not exist then "does not equal" evaluates to True. Again, do not add quotes to the value you enter. |
| has a value | The case property must exist and must have a value other than a blank string or string with spaces. |
| does not have a value | The opposite of "has a value". |
...
| Option | Description |
|---|---|
| The time from case property | When scheduling the content, the system will inspect this case property on the case that matched the rule. If this case property's value is a time (a string in the 24-hour format HH:MM), then it will schedule the content at this time. Otherwise, it will default to scheduling the content at 12:00. |
...
Start Date
For Daily, Weekly, and Monthly schedules, you have a few options for the Start Date of the schedule:
...
| Recipient Type | Description |
|---|---|
| The Case | The case which matches the rule will be a recipient. See Registering a Case Contact. |
| The Case's Owner | The owner of the case which matches the rule will be a recipient. If the owner is a user group, then all users in that group will be recipients. If the owner is an Organization, then all users assigned to that Organization will be recipients. |
| The Case's Parent Case | The parent of the case which matches the rule will be a recipient. Note: This only works for parent/child relationships and not host/extension or parent/extension. If this is used with host/extension relationships, the SMS or email will not send and the error in the Messaging History Report will display as "Error - No recipient". |
| User Specified via Case Property | A commcare user whose username is a case property of the matching case. The case property in which to look up the username is specified in a text box under the recipient choices. The user must be a mobile worker in the same project space. |
| Email Specified via Case Property | An email address found in a case property of the matching case. The case property in which to look up the email address is specified in a text box under the recipient choices. This option can only be used for email alerts, not SMS ones. |
...