When orchestration rules are active, USM Anywhere inspects and validates them to show how well the rule is working.

The orchestration rule validation process is engaged whenever a new rule is created or an existing rule is updated. Additionally, active rules are validated periodically for the duration of the time they are active. The orchestration rule validation process checks your rule against a set of tests, called rule checks, which evaluate how well your orchestration rule will perform, and checks it for common errors. For example, this validation process keeps you from creating a rule that will collect nothing (or everything).

For every rule check that your orchestration rule fails, you are shown a status notification, which explains in detail what should be improved in your rule. Each status notification is classified by its severity into four statuses (in increasing severity): ok, info, warning, and error. While an info-level status notification may indicate that optimizing the rule would be useful, a warning-level status notification indicates a more critical problem that should be addressed. An error-level status notification will prevent you from saving the new rule until it is fixed.

Viewing Your Rule's Validation Status

To view the validation status of your orchestration rules, go to Settings > Rules. The rule's status is indicated by a column on the Orchestration Rules main page. If you would like to view just the rules that have a specific status, you can filter by validation statuses from the All Orchestration Rules page.

To read a detailed breakdown of your rule's validation, click the rule. This opens a window listing the details that apply to your rule, with an icon indicating each status notification's severity. From this view, you can see a clear list of all the changes you can make to optimize your rule. You can also see any changes that are required for your rule to function.

Understanding How Validation Is Assessed and Applied

When more than one validation check applies to an orchestration rule, USM Anywhere considers the most severe of those the rule's validation status. For example, in the screenshot, you can see that a warning, info, and error notifications were all triggered by the "Alarm without Condition" rule, so its overall validation status is error.

The following table shows the list of validation statuses.

List of Orchestration Rule Validation Statuses

Status	Icon	Description
INFO		There are minor issues in this rule's definition that might affect your rule's operation.
WARNING		There are issues in this rule's definition that might negatively impact your system.
ERROR		This rule will present undesired behavior on your system.

Rule Validation Lifecycle

Your rule's validation status will persist as long as the rule checks that apply to it are active. Status checks are either static or dynamic. Static checks evaluate your rule against common mistakes when your rule is first created, while dynamic checks analyze your rule's behaviors and are assessed every 10 minutes while your rule is active.

Both static and dynamic checks show up as status notifications on your orchestration rule.

Static Checks

These checks evaluate your rule against common mistakes such as the presence of a data source or packet type, in addition to validating fields like IP and operator. Some of the static checks will prevent users from creating or updating a rule if they fail.

Rules are evaluated immediately against static checks when they are created or updated. Static checks don’t have a predetermined lifetime and will persist until the triggering condition is fixed or removed from the rule. They will be ignored in scheduled purge tasks used to clean invalid rule checks.

Dynamic Checks

These checks will analyze your rule's behaviors, like their match ratio or how quickly they are processed. They are evaluated as long as your orchestration rule is active.

Active rules are evaluated against dynamic checks every 10 minutes with the help of a scheduler task. Dynamic checks have a predetermined lifetime of 7 days. During those 7 days, another scheduler task runs every 6 hours to confirm whether those dynamic checks still apply to your rule. If the conditions for that check haven't been seen on your rule for 7 days, the check and its related status will be removed from your rule.