How come itom engineer will understand the alert/incident at the application service level?

[KM SN]

If alerts are intentionally mapped to a non‑host CI such as an Application Service to notify the application team about service degradation, how can the team still identify which downstream infrastructure CI actually caused the issue?

[KM SN]

But definitely you can't see the issue ci just seeing the service map, right?

[Gary Ault]

Alert table business rules to change the assignment groups based on rules. 
Kind of a crazy idea, but it worked for us.  We wanted to alert to be bound to the CI causing the problem, but in some cases needed a different assigned group than the CI support group. 
There really needs to be more flexibility on determining assignment groups for alerts.   Sometimes CIs have different ownerships at different levels.  (app teams, dba's, middleware teams, server admins).

There should be a better way, but if there is I didn't find it. 

[Jeff K1]

What we've done is allowed for a key value pair to be passed in Additional Info that we will process if it exists and assign the incident to that assignment group, while still keeping the incident tied to the bound CI.

Something like:
"assignment_override": "Override Group"

This allows each source to control it while working with their customers. And for sources that might not be able to pass it, we can assist with a Field Mapping.