Here is additional context.

The objective is to use Informational Events (enabled via the Info column in the Alarm Template) instead of Alarms, as the goal is simply to track specific events without assigning severity levels. Therefore, all severity parameters were left blank in the Alarm Template configuration.

Alarm Template Configuration
* Filter: Set to "*" to include all rows.
* Info Column: Checked, with the event type specified as "fault".
* Condition: Configured to track only rows where "User field 1" equals "active".

Observed Behavior

Despite the configuration:
* Condition logic was ignored: Any row entering "fault" status triggered an Informational Event, even if "User field 1" did not equal "active".

* Row-level filtering was ineffective: Updating the Filter to target specific rows (e.g., Input 1 through Input 9) produced no change, all rows still triggered events upon entering "fault" status.

* As a result, every fault event, regardless of its row or conditional context, was picked up by the correlation rule, leading to unwanted Slack notifications.

Thus, the reason for my question, as it seems that.
* Filter and Condition logic in Alarm Templates is only evaluated for severity-based alarms.

* Where, Informational Events configured using the Info column do not appear to honor these settings.

Resolution:
To achieve the intended behavior, where only specific condition-matching rows trigger events, the Alarm Template was revised to use severity parameters.

* Severity levels were defined in the Alarm Template (e.g., Warning, Minor).

* Filter and Condition logic then operated as expected, properly constraining which rows could trigger alarms.

* As a result, only targeted rows that met all criteria generated alarms and subsequently triggered correlation rules (e.g., Slack alerts).