Hey @girijasankar
Based on the behavior described, the fact that the OOTB Create Incident subflow works when executed manually is a good indication that the subflow itself is probably not the primary issue.
The important thing to troubleshoot is the automatic execution of the Alert Management Rule. Since some Alerts create and attach an Incident automatically while others do not, I would compare one successful Alert with one unsuccessful Alert.
1. Check Alert Execution
Open the Alert where the Incident was created and navigate to the Alert Executions related list.
Verify:
Alert Management Rule
Action Name
Automatic Run
Related Task
Execution Log
Then perform the same check on an Alert where the Incident was not created.
This will immediately tell you whether the Alert Management Rule actually reached the Create Incident action.
If there is no Alert Execution record for the failed Alert, the problem is before the Create Incident subflow. In that case, focus on the Alert Management Rule filter, rule order, grouping, and execution conditions.
If an Alert Execution exists but the Related Task is empty, then investigate the Create Incident action/subflow execution and its log.
2. Check the Automatic Execution Limit
This is one of the first things I would verify.
Open the Alert Management Rule and check the configuration for the action that invokes Create Incident.
If an automatic execution limit has been configured and that limit has already been reached, subsequent matching Alerts may not create Incidents automatically.
This can produce exactly the type of intermittent behavior described:
Alert 1 creates Incident
Alert 2 creates Incident
Alert 3 creates Alert but no Incident
Alert 4 creates Alert but no Incident
For testing, verify that the automatic execution limit is not preventing the action from running.
3. Check Alert Grouping
If Alert Grouping is enabled, compare the working and non-working Alerts.
Check whether the problematic Alert has become a secondary Alert or has been associated with another Alert group.
Also check:
Role in group
Parent Alert
Maintenance status
Existing Related Task
Alert state
This is important because the Alert that triggers Incident creation may not always be the same Alert that you are looking at after grouping/correlation processing.
4. Check Whether an Incident Already Exists
The OOTB Create Incident logic should not create another Incident when an Incident is already associated with the Alert.
Therefore, open the problematic Alert and check whether a Related Task or Incident is already present.
Also compare the working and non-working Alerts rather than only checking the Incident table.
5. Review the Alert Management Rule Conditions
From the screenshot, the Alert Management Rule contains multiple conditions around:
Severity
Resource
Type
Description
Because several conditions are combined with OR/AND logic, I would verify the final condition grouping carefully.
The fact that an Alert is created by the Event Rule does not necessarily mean that the Alert will satisfy the Alert Management Rule.
The Event Rule and Alert Management Rule are separate stages.
The Event Rule creates the Alert.
The Alert Management Rule evaluates that Alert and determines whether the configured action, such as Create Incident, should execute.
6. Check Rule Order and Other Alert Management Rules
Also check whether another Alert Management Rule is matching the same Alert.
Review:
Active Alert Management Rules
Order
Multiple alert rules configuration
Other actions configured against the same Alerts
Another rule could potentially process or modify the Alert before the Create Incident action executes.
7. Compare One Working Alert and One Failed Alert
I would recommend creating a simple comparison during troubleshooting:The Alert Execution record and execution log are the most important pieces of information here.
8. Simplify the Rule for Testing
As a temporary troubleshooting step, I would simplify the Alert Management Rule and use one deterministic condition.
For example:
Severity = Critical
Action:
Create Incident
Run it against several test Alerts and check whether every matching Alert gets an Alert Execution and Incident.
If that works consistently, gradually add the Resource, Type, and Description conditions back.
This helps determine whether the issue is related to the filter logic.
*************************************************************************************************************************************
If this response helps, please mark it as Accept as Solution and Helpful.
Doing so helps others in the community and encourages me to keep contributing.
Regards
Vaishali Singh
Servicenow Developer
Linkedin - https://www.linkedin.com/in/vaishali-singh-2273361bb
