Alert triggers

Reporting > Action > Alerts > Triggers

Triggers determine when an alert workflow activity (known as Action) should happen. Actions say what to do based on some condition, while triggers say when to do it. A trigger for an alert instance waits some specified length of time and then checks to see if its trigger conditions are still true. If they are, the action happens; otherwise, the activity expires with no action. A trigger can be reactivated if the initial condition again becomes true. Actions might include sending email notifications, moving alerts to different statuses, and assigning the Alert instance to a role.

Each trigger defines:

The conditions that must exist for the trigger to fire.
How long to wait before triggering.
The action to take when the trigger fires.
The alerts the trigger applies to.

Note: The order of triggers in the list of triggers has no impact on the priority or processing-order of the triggers. Rather, it is the timers that affect when and which triggers happen, and the Alert status conditions define the state the alert must be in before a timer is set. It is possible to define two triggers to happen at the same time, in that case both are evaluated, but the priority is not defined.

Trigger properties

Name: Required. Name of the trigger.
Action to run: Required. Action to run when the timer delays fire and the trigger conditions are valid.
Assignee condition: The Assignee that is already assigned to the alert instance before this trigger is valid. For example, if the alert is assigned to a role named Top Tier, and this trigger condition only applies to an assignee role named In Store, the condition is invalid and the trigger expires without running the action. When this condition is None, all Alert instances apply and this condition is always valid.
Alert status conditions: One or more states the Alert instance must be in before this trigger is valid. If none are selected, all statuses apply. For example, if this trigger must be in New or In Progress state, but the Alert instance is in Overdue when the trigger fires, this condition is invalid and the Action never runs.; Note: This is setting is easy to overlook and is the cause of many misconfigured Alert workflows. Triggers are invalid for Alert instances not in one of these states. In general, Alerts go from a one state to another state. This is the “from”, and the Action to Run is the “to.” See the discussion of Pitfalls in the Advanced alerts overview.
Relative delay: The period of inactivity before taking an action; how long to wait before firing a trigger. The relative timer resets when the alert instance changes state, or a User enters a comment when the instance is in the New, Overdue, or In Progress states. See Delays and timers for a complete discussion of how delays works.
Absolute delay: How much time may pass — since the trigger condition was true — before firing the trigger. See Delays and timers for a complete discussion of how delays works.
Alert types for this trigger: Alert types (Alert conditions) this trigger applies to. Only alerts instances of these selected types are affected by the trigger.; Only Alert types that are Active are available for selection in the list.

Important: Removing an Alert type from a Trigger does not stop an instance with an Absolute delay of the Alert from being triggered. Absolute delay conditions are set when the alert instance is created, and they are never again evaluated against the Trigger definition. As such, removing an Alert type from a trigger does not affect any open instances: the absolute trigger will still fire. The only way to stop an instance from being triggered is to close it. Reopening an alert causes all Absolute conditions to be reevaluated.

Delay specifications

Delays are defined as lengths of time as integers, and time segments the length applies to as either 'd' (day), 'h' (hours), and 'm' (minutes). The specification can include any combination of segments. For example:

2d 10h 3m
11h 59m

Restriction: Alerts are processed once every 15 minutes. Setting time lengths less than that is not practical. Best practice is to define intervals of no less than 1 hour.

Delay testing frequency

Delays are measured in days or hours, where a day is 24 hours from when the alert instance was created. Medallia Experience Cloud evaluates delays once-per-hour, so it is possible an activity might not happen for almost an hour later than specified by the delay. As such, smaller measurements have little effect.

Illustrating that the action typically happens some time later than the actual delay based on when the test happens.

Note: Changing the length of time does not affect alerts that are already triggered. For example, if an "overdue" was scheduled to happen after 1 day, and the delay is changed to 7 days, the change does not affect any alerts already counting-down the 1 day delay: the action will still happen after 1 day. However, all new triggers will use the new delay.

Tips

Editing the definition of a trigger with open instances affects the Relative delay but not the Absolute delay.
Be sure to account for the In progress state when defining the trigger. See Pitfalls for details.
An activity with no delays is evaluated when the alert instance status changes. Use this to send notifications and perform an assignment when the alert enters the new state.