Configuring ML-based situations
As a tenant administrator, you can configure how events are correlated into ML-based situations and how similar situations are grouped. These configurations help you manage related events efficiently, reduce noise, and support faster identification of root causes.
To access the Manage Situations page, enable the AIOps Situations feature from the Manage Product Features page. After the feature is enabled, you can configure the ML-based situation settings to control how events are correlated into situations and how similar situations are grouped into primary or related situations.
To enable multi-service situations
On the BMC Helix AIOps console, click Configurations, and then click Manage Situations.

From the Manage Situations page, enable the Multi-service Situations option.
This option determines whether events are correlated across topologically connected services or restricted to an individual service.When enabled (default):
Situations include events from CIs outside the defined service.
Root Cause Isolation considers cross-service dependencies.
Situations become fewer but broader, spanning multiple services.
When disabled, event correlation is limited to individual services. Separate situations are created per service, with no cross-service correlation. Frequently enabling or disabling this feature can affect in-progress situations. Change this setting only after reviewing operational impact.
After you enable this option, to include external CI events in the service health score calculation, enable the Include external CI events in health calculation option from the Manage Service Health page. For more information, see Configuring global settings for service health.
To configure situation settings
On the BMC Helix AIOps console, click Configurations, and then click Manage Situations.

On the Manage Situations page, configure the following settings:
Option Description Correlation Event Time Window (in mins) Determines whether two events with the same signature can be correlated, provided the signatures are also correlated from the topology and temporal aspects. If all these conditions are met, the events are correlated, and any event that comes after the set time limit is not correlated into a situation.
Drag the slide bar to set the window. By default, it is set to 15 minutes.
Example: You have an event sequence with three events that occurred when CPU utilization is at 90%, 93%, and 97% at 05:00 hr, 05:10 hr, and 05:13 hr. All these events have the same signature. According to the correlation event time window, they are grouped into a situation, as they are temporally and topologically related.
Situation Stability Window (in mins) Determines situations' stability or saturation. The situation attains saturation or stability if there are no new event signatures to be aggregated within the set time limit. If there are new event signatures to be aggregated, the stability window is reset until there are no more new event signatures.
Drag the slide bar to set the window. By default, it is set to 30 minutes.
Advanced Settings Show Policy-based Situations Determines whether to show or hide the policy-based situations on the Overview and Situations pages. When enabled, the policy-based situations are listed along with the ML-based situations in the console.
Toggle the option to show or hide the policy-based situations along with the ML-based situations. By default, this option is enabled.
Expiry of Similar Situation Group (in days) Determines the maximum number of idle days for a group of similar situations to be marked as expired. A group is expired if no new similar situations are added to it within this period. After the expiry time, any new similar situation is not associated to the expired group.
Drag the slide bar to set the days. By default, it is set to 30 days.
Similar Situation Detection Window (in hours) Determines the hourly interval to detect similar situations and form the groups. The similar situations detection policy runs according to the specified interval, and a group is formed if two or more stabilized situations are identified to have similar message, impact, and node ID (service node). Based on the identified similarity, either the new situations are added to an existing group or a new group is formed.
Drag the slide bar to set the window. By default, it is set to 24 hours.
Save the changes.
Correlation behavior used for creating ML-based situations
The creation of ML-based situations depends on whether the Multi-service situations feature and the Same signature correlation option are enabled.
The following table describes how different combinations of these settings impact situation formation:
| Multi-service situations feature status | Same signature correlation status | Scenario | Outcome |
|---|---|---|---|
| Disabled | Disabled | Two events occur on the same node with the same signature. | The situation is not created. |
| Disabled | Enabled | Two events occur on the same node with the same signature. | The situation is created. |
| Enabled | Disabled | Two events occur on the same node (single service) with the same signature. | The situation is not created. |
| Enabled | Enabled | Two events occur on the same node (single service) with the same signature. | The situation is created. |
| Enabled | Disabled | Two events occur on the same node (single service) with different signatures. | The situation is created. |
| Enabled | Disabled | Two events occur on the same node but belong to different services, with the same signature. | A multi-service situation is created. |
Where to go from here