TrendSeeker
HomeBlogDocsContact
  • Overview
    • Try It!
    • Introduction
    • Key Features
    • Videos
    • Reviews
  • Technical Docs
    • Getting Started
    • TrendSeeker Rules
    • TrendSeeker Correlations
    • TrendSeeker Metrics
    • Threshold Scripts
    • Logging
    • Troubleshooting
    • Frequently Asked Questions
Powered by GitBook
On this page
  • What to Detect
  • How to React
  1. Technical Docs

TrendSeeker Rules

PreviousGetting StartedNextTrendSeeker Correlations

Last updated 11 months ago

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 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

What to Detect

  • 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

Schedule

  • 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

  • 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).

Timing

  • 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.

How to React

  • 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:

    • 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)

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 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 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)

record/current: record

Threshold Scripts
TrendSeeker Metrics
TrendSeeker Correlation
TrendSeeker Correlation
TrendSeeker Rule
What to Detect
How to React