Delays and timers

For flexibility, Triggers have two timers:

Absolute delays specify how much time may pass — since the trigger condition was true — before an action must take place, such as moving an alert into a specific state.

Illustrating when various absolute delays can take place based on the state of the alert

Relative delays identify periods of inactivity before taking an action. The relative timer resets when the alert instance changes state, or a User enters a comment.

Illustration showing relative delays resetting each time the alert changes state

When a delay period passes, Medallia Experience Cloud verifies the trigger's condition and delay settings are valid. When both are valid, the action occurs; otherwise, the trigger expires with no action.

Note: An activity with no delays is evaluated each time the Alert status changes. Use this to send notifications and perform an assignment when the alert enters a new state.

Using both delays in one activity

By using both absolute and relative delays, a company can establish policies to ensure an alert is being followed up on, while still setting absolute limits on how long the work should take. This example demonstrates the value of using both delays. A company wants every issue to be worked on at least once a day, but no issue should be New or In Progress for more than four days. In either case, the alert should be changed to Overdue. In this case, the user has made several notations to the alert, and each time the relative delay is reset.

Illustration showing an Absolute delay trigging an action, even though the relative delay has been reset several times

The following illustration demonstrates three workflow activities and their timer delays. Three of the delays expired because they were not in the proper condition (state) when the time elapsed. Eventually, the relative timer caused the workflow to change state, even though it resets twice before firing.

Illustration as explained in the previous paragraph

Note: When using both delays on activity, the one which will trigger the soonest is the one shown on the Responses Form banner.

Business day exclusions

Alert business days are the days of the week timers use when calculating trigger delays. The basic idea is no workflow activities are triggered during non-business days, and the excluded days are ignored when calculating a timer delay. This keeps overdue, escalated, and exclude actions from happening when there is no one at work to handle it. For example, when Saturday and Sunday are excluded, and an overdue timer is set to expire at 11:00 a.m. on Saturday, it will not actually expire until Monday at 11:00.

Two alert triggered on Wednesday and each of three day delays: one action happens on Saturday and the other on Monday because it excludes weekends

See Alert business days for more information.

Note: All calendar operations are based on the Time Zone setting for the company's primary Unit Group, as defined in Unit groups admin.

Notification or warning activities

Warning activities are ones that send notifications but do not change the state or assignment of the alert instance. Companies typically use these to warn the assignees that a state change is about to happen. For example, if there is an activity to escalate an alert after 5 days, there might be a warning activity after 4 days.

Illustration of a warning action after four days, with an escalation after five days

Timers and reopened alerts

Closing an alert stops all triggers for that alert. However reopening an alert puts that alert back into In Progress state. When this happens:

  • Absolute timers reset and trigger again when the conditions become true.

  • Relative timers reset from the timestamp when the alert was reopened.