Hi Uwe,
I dont know if I understand your question properly:
Do you want to define one Escalation Policy on the Service Alarm, which then acknowledges all underlying impact/root cause alarms?
This is not possible out of the box.
Escalation policies only work on the Alarm that is trigggering them.
The above scenario would require a search in the DB to find all Alarms that belong to this Service Alarm and acknowledge them individually.
Even when using a script in the Escalation Policy that is doing this, there are many different scenarios to consider.
For example: This has to be refreshed all the time, because the Service Alarm might still be the same, whilst the root cause has changed.
I would like to get a better understanding of your processes regarding tickets for Service Alarms:
How do you handle the situation that a single device is modeled in two Services and thus causes two Service Alarms when it has a problem.
Do you create two tickets, or how do you match these?
Whom is the ticket assigned to in the ticket system - do you have matching Services and Ticketing groups?
Which CI is used in the ticketing system to be handled as the "faulty" one - do you have Service objects?
MichaelBoehm