Event Management: Incident auto-assigned to previous engineer instead of only assignment group

[nameisnani]

Hi Team,

We are observing unexpected assignment behavior when incidents are created from Azure Monitor alerts via Event Management.

🔹 Scenario

• Alert Source: Azure Monitor

• Alert creates incident via Alert Management Rule + Flow Designer subflow

• Assignment group is set correctly

• Incident is also auto-assigned to the engineer who handled a previous incident for the same CI

🔹 Expected Behavior

Incident should be assigned only to the assignment group, allowing the team to take ownership.

🔹 Actual Behavior

Incident is created with:

• Assignment group → correct

• Assigned to → previous engineer (system set at creation)

This gives the impression that the ticket bypassed the group.

---

🔹 What we verified

✔ Alert Management Rule does NOT set Assigned To
✔ Flow Designer subflow sets only Assignment Group
✔ CI has no owner or assigned user
✔ Alert record does not contain Assigned To
✔ Assignment is set by “System” at creation

---

🔹 Question

1. What mechanism in Event Management can cause the incident to inherit the previous engineer?

2. Can this be due to:

   • Incident Assignment Rules?

   • Event Management correlation behavior?

   • Historical CI routing logic?

3. What is the recommended approach to ensure incidents are assigned only to the group?

---

🔹 Environment

• ServiceNow Event Management

• Azure Monitor integration

• Incident created via Alert Management Rule + Flow Designer

---

🔹 Goal

Prevent auto-assignment to a specific engineer and route incidents to the assignment group only.

---

what needs to here - please help us - where we need to check - 

Thanks

[vaishali231]

hey @nameisnani 

Based on your validation:

Alert rule does not set Assigned To

Flow sets only Assignment Group

CI has no owner

Alert record does not contain Assigned To

Field is populated by System at insert

This strongly indicates that the assignment is happening at the platform level during incident creation.

Possible Causes

Incident Assignment Rules

Active assignment rules on the Incident table may contain conditions or script logic that:

Look up previous incidents for the same CI

Copy the last assigned engineer

Apply routing logic beyond just Assignment Group

Assignment rules execute during record insert and can populate Assigned To even if Flow does not.

Before Insert Business Rules

Custom business rules on Incident (Before Insert) may query the most recent incident for the same CI and set assigned_to programmatically.

Predictive Intelligence or Advanced Work Assignment

If enabled, Predictive Intelligence may auto-assign incidents based on historical patterns. This often appears as if the system is inheriting the previous engineer.

Incident Reuse or Correlation

If the alert is reopening or correlating to an existing incident rather than creating a brand-new record, Assigned To may persist from the original incident.

 Solution for this case:

Option 1

Update assignment rules to exclude incidents where Source = Event Management (or Contact Type = Alert).

Option 2

Add logic in Flow Designer after incident creation to explicitly clear Assigned To.

Option 3

Create a defensive Before Insert business rule:

If source = Event Management

Then set assigned_to = empty

******************************************************************************************************

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

[nameisnani]

@vaishali231 

Hi Vaishali,

Thank you for the detailed guidance — it helped us narrow down the behavior.

Here is what we have verified in our environment:

• Alert Management Rule does not set Assigned To
• Flow Designer subflow sets only Assignment Group
• CI record has no owner or assigned user
• Alert record does not contain an Assigned To value
• Assignment is populated by “System” at incident creation

We also reviewed Incident Assignment Rules and did not find any rule explicitly routing based on CI or previous resolver.

One additional observation: the alert was in a Reopen state and has a parent alert, which suggests correlation/reuse behavior for the same CI. This may be allowing the platform to retain historical handling context when creating the new incident.

We are currently evaluating whether this behavior is part of Event Management correlation logic or platform-level routing.

Please let us know if you have seen similar behavior where reopened/correlated alerts influence Assigned To during incident creation.

Thanks again for your insights.

[lauri457]

Check the "Reopen associated closed incident" business rule on [em_alert]. Identical events will cause the alert to reopen (or not, see sysprop evt_mgmt.alert_reopens_incident) if it happens within the timeframe set in sysprop evt_mgmt.active_interval.