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

[MortenPettersen]

I believe the purpose of the community forum is to just offer tips based on your own experiences. Something that can help the person debug on their own. One of the premises of offering help is that we accept that we don't have access, no?

[nameisnani]

@Ankur Bawiskar  need your help here - could u please hlpe me 

[Ankur Bawiskar]

@nameisnani 

not very sure on this.

[Mark Manders]

Log a case with ServiceNow. The handling of events can be tracked only to a certain level. Some of it is very black box.

Next to that: we don't know your instance. There could literally be hundreds of things going on here. Event rules creating the alert, alert rules creating the incident. Reopening, grouping, timing. It's already difficult to track when you do have access to an instance. We don't have that access, so ServiceNow support is you go to (even though I fully realize that their knowledge level is probably not enough to solve it, but you can try).

Do this quickly, before there is nothing to track anymore. Events get cleaned!!

[chipillasra]

1. "Similar Incident" Auto‑Assignment 

ServiceNow Incident has an invisible logic that assigns an incident to the same engineer who closed the most recent related ticket for the same CI or category.

This behavior typically comes from:

Assignment Workbench "Historical Assignment" algorithm

If your organization uses Assignment Workbench, one of the built‑in algorithms is:

Historical records → Prefer the user who resolved similar incidents for the same CI or category.

This happens even if:

• Your Flow sets only assignment group 

• No assignment rule sets Assigned To 

• CI has no owner 

ServiceNow will still say “system” because Assignment Workbench runs at creation silently.

How to confirm

Check the system logs:

System Logs → Application Logs → Source = com.snc.assignment_workbench

If you see evaluation activity at insert time → this is the cause.

Other Possible Causes (in order of likelihood)

2. "On‑call Scheduling" Auto‑assignment

If the assignment group has on‑call rotation, and you set the group, ServiceNow may auto‑populate the on‑call person.

But in your case you said:  Assigned user is the engineer who handled previous incidents
 Not the on‑call person
So this is unlikely.

---

3. Incident Assignment Rules

Even if you believe they are not used, check specifically:

Go to:

System Policy → Rules → Assignment Rules
Search for rules that run on:

• Table = Incident

• Condition uses CI fields

• Action sets "Assigned To"

Sometimes customers have hidden/global rules like:

If CI = X → assign to last resolver

---

4. Knowledge‑based Assignment Plugin (less common)

If the plugin

com.snc.knowledge_related_auto_assignment
is active, it may auto‑assign based on prior case similarity.

Rare in Event Mgmt contexts, but still possible.

---

5. Custom Business Rule on Incident

Many organizations have a BR called something like:

• "Autofill Assigned To"

• "Populate resolver"

• "Best Guess Assignment"

Look for: System Definition → Business Rules
Filter:

• Table = incident

• When = before insert

NOT candidates

To answer your explicit questions:
Event Management does NOT assign “Assigned To” automatically

• EM does correlation

• EM maps fields

• EM does NOT assign users

 Azure Monitor integration does NOT set Assigned To

Correct.

 CI ownership does NOT apply (you verified the CI has no owner)

---

Recommended Fix: How to Force Assignment Only to the Group

Option 1 — Hard‑block Assigned To at creation

Create a Before Insert Business Rule:

if (current.operation() === 'insert') {

    current.assigned_to = '';

}

Option 2 — Disable Historical Assignment Algorithm

In Assignment Workbench → Administration → Algorithms, deactivate:

• Historical Resolver

• Similar Incident Handler

---

Option 3 — Add a Flow Action After Incident Creation

Immediately clear Assigned To:

Update Record → Incident 

Set Assigned To = Empty

Option 4 — Restrict Assignment Rules

Remove or rewrite any assignment rules referencing:

• CI

• Category

• Previous resolver