Wait Rules
Wait rules are used in conjunction with Creation Rules/Incident Creation Rules for introducing a delay between a SCOM alert being received by ServiceNow and an Incident being raised.
Why hold back alerts?
Wait rules are useful in cases where an alert might be closed in a short amount of time after being raised (for example, a monitor for CPU thresholds or port flapping).
Consider the example of a CPU monitor that raises an alert when CPU load goes about 80% and automatically heals when CPU load drops back below 80%
In this example, spike 1 is ~1 min and spike 2 is ~5 mins. Without wait rules, you would likely get 2 alerts (and therefore Incidents) from a monitor here. An Incident for both alerts may be desired here, but isn't likely to be in all cases.
Wait Rule Properties
As with standard Incident Creation Rules, a Wait Rule contains criteria that a SCOM alert must hit, which means specific alerts can pass through a single wait rule only.
Wait Rule: Unless this box is checked, the rule is a Creation Rule. Check this box to make the wait rule. Doing this will disable Advanced Creation and Advanced Updates scripting options and remove Configuration Item and Assignment Group options (as they don't apply to wait rules)
Name: the name of the wait rule you are creating
Alert Condition: The condition that an incoming SCOM alert must meet to match this rule. The conditions available are the same as those for Creation Rules, read more here.
Wait Duration: How long the SCOM alert should be held before being evaluated against other rules on a lower priority (processing order)
Description: A friendly description of the Wait Rule
Active: Specifies whether this Rule is active or not (default is inactive)
Processing order: The order that this Rule is processed. Lower numbered rules are processed first (IE 1 is the highest priority), an alert can flow through a single wait rule only before hitting a Creation Rule. ServiceNow will not process lower priority rules once it has found a match on a higher priority one.