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

[nameisnani]

how it got updateed - can anyone please help me find out .

system comments from where it is updatd

[lauri457]

This sounds like the behaviour governed by evt_mgmt.alert_reopens_incident. if this prop is "new" it will create a new one and the fallback is to copy values from the closed/resolved incident. Also the interval is to the updated timestamp not created and if it's state is reopen then that would indicate that it was indeed reopened and not registered as a new issue? I might be misunderstanding something

[nameisnani]

@lauri457

[Mark Manders]

Did you already log this with ServiceNow Support to have them check? Be advised that Event related data is only around for a short timeframe, so have them take a look at it asap. We don't have access to your instance while they do. 

As already mentioned: there can be lots and lots of things going on here which is hard to troubleshoot even when you have access to everything. 

[lauri457]

This is what the documentation tells you about property evt_mgmt.alert_reopens_incident which for you is set as "new" as in create a new incident don't reopen the existing one.

• If the incident is Resolved or Closed, the incident is reopened, a new incident is created, or nothing is done, depending on the evt_mgmt.alert_reopens_incident property value.
  • If the incident is reopened, work notes are added to the incident.
  • If a new incident is created, any matching alert management rule, alert action rule, and task template applies to the incident. If there is no matching alert action rule or template, fields from the existing incident are copied to a new incident.

This and the work note "The related alert {0} is now unlinked from the previous {1} {2}" implies that it matched a deprecated alert action rule not an alert management rule.

As said by @Mark Manders it is impossible to debug without access to the instance. But it should be quite simple to just export the records to an upstream instance and simulate the event processing to verify the behaviour.