TrendSeeker Rules
Last updated
Last updated
TrendSeeker Rules are the heart of TrendSeeker - they define the trends to monitor for a given table, and how to react when a trend is identified. When a trend is detected, a TrendSeeker Correlation record is always created, in addition to other activities configured on the TrendSeeker Rule. You can create a TrendSeeker Rule for any table in your ServiceNow instance, including global, custom, and scoped tables.
The TrendSeeker Rule form is organized into tabs to simplify configuration:
What to detect: Configuration of what trend to monitor for on a particular table
How to react: Configuration of what to do when a trend is identified
Detection table: Table on which to monitor for a trend
Apply aggregate?: Enable/disable measuring records matching the Condition, but also grouped on the Aggregate field (ie - Count of records with same Category). When disabled, TrendSeeker measures all records matching Condition
Condition: Conditions which must be met in order for a record to be included in the count
Apply schedule: Enable/disable only including records created outside (Exclusive) or inside (Inclusive) of a given schedule. This is useful when accounting for blackout/change window or other 'non-normal' time periods.
Threshold type: Type of threshold to apply when measuring record counts to identify a trend
Direction: Whether a trend should be triggered when a count is 'Above' the detected threshold (ie - an abnormally high number of Incidents) or 'Below' the detected threshold (ie - an abnormally low number of records created by an integration).
Threshold script: When using a Scripted Threshold type, the Threshold script is assessed to calculate the threshold value, usually based on historical performance. These are stored in the Threshold Scripts table.
Statistical window: The running number of past days over which statistical measurements are used when calculating the Threshold script. All statistical measurements can be found in the TrendSeeker Metrics table. (Note: Statistical measurements will accrue over time after a rule is created. Until a full window of historic measurements is accrued, the available values will be used)
Frequency: How often to check for this trend (15 minute minimum)
Timeframe: Timeframe backwards, from the moment the rule runs, over which to include records from the Detection table when identifying a trend
Cooldown: Amount of time until an active TrendSeeker Correlation expires
Cooldown basis: On TrendSeeker Correlation origination, time from which to begin the Cooldown timer.
Trend Detection: Time at which the most recent record in the trend was created
Correlation Created: Time at which the TrendSeeker Correlation was created
Detection resets cooldown timer: When enabled, each new detection matching the TrendSeeker Rule will restart the cooldown timer. When disabled, the cooldown timer will always count down from when the TrendSeeker Correlation was instantiated.
Frequency, Timeframe, and Cooldown durations are automatically rounded up to the nearest minute
The Timeframe duration should never be larger than the Cooldown duration, or else conditions may arise where a TrendSeeker Correlation is both detected and cooled-down simultaneously
If you need to run TrendSeeker Rules on-demand, do so via the API call
new x_yala_trendseeker.YansaTrendSeekerHelper().runRules(encQuery)
where encQuery is an encoded query matching the rules you wish to run.
Trigger event?: Trigger an event on detection of a trend. This is useful for triggering notifications or other actions within ServiceNow that aren't otherwise accommodated by the TrendSeeker Rule. Event parameters:
record/current: TrendSeeker Correlation record
parm1: Comma-separated list of associated Destination table record SysIDs
parm2: Aggregate field display value
Create record?: Create a record on detection of a trend, applying a Template or setting record values via Creation script. An example is creating a Problem record when an above-average number of Incidents is found matching certain conditions.
Run script? (initial detection): Run server-script on initial creation of a TrendSeeker Correlation. Useful for performing actions that may only be applicable on initial detection, such as gathering a list of related Incidents to add to a Problem record.
Run script? (additive detection): Run server-script on detections that add records to an existing TrendSeeker Correlation. Useful for performing actions that may only apply to subsequent additions to a trend, such as relating a single new Incident to a Problem record.
Run script? (always): Run server-script on all TrendSeeker Rule runs for an active correlation, even if no additional matching records are found. (Note: Does not run on initial TrendSeeker Correlation creation, but does run for every subsequent TrendSeeker Rule run while the TrendSeeker Correlation is active)
