Issue Summary

When an automation rule under an Operations Team is used to create an incident on a JSM project, the automation rule automatically sets the incident "Responders" field to the Team that owns the automation rule.

If the "Responder alerts" feature is enabled in that same project, the project will try to create a responder alert (Responder/Owner/etc).

However, if the Team is a service owner and the automation rule creates an incident for that service ("Affected Services" field), the Team will be considered both "Responder" (set automatically by the automation rule) and "Owner" (as a service owner). This causes a race condition to generate the Responder Alert, sometimes a "Responder" alert type is generated, and sometimes an "Owner" alert type is generated.

This seems like a race condition, where the first type which processing is completed, is generated.

Steps to Reproduce

1. Create a service and set a test Team as owner (Team One for the below steps).
2. Enable "Responder alerts" under Project settings > Operations > Incident Management.
3. Create an automation rule under "Team One" Operations.
   1. Trigger - Alert Created
   2. Action - Create incident > Set the "Affected services" field to the same service as the 1st step.
4. Create a new alert and set "Team One" as the responder. This can be done using the ... > Create alert function on the "Alerts" view.

Expected Results

• A new JSM ticket will be created.
• This will trigger the "Responder Alerts" feature.
  • A new "Responder Alert" should be created, and be the same type always (Responder or Owner).

Actual Results

• The "Responder Alert" type is inconsistent. Sometimes an "Owner" alert type is generated and others a "Responder" type.
• If the "Affected Service" owner is a different team (for example *Team Two), then both "Responder" ("Team One") and "Owner" ("Team Two), will be created correctly.
  • The problem occurs when the same Team is both "Owner" and "Responder".

Workaround

Currently there is no known workaround for this behavior. A workaround will be added here when available