I have been testing Incident Management (IM) with focus on the notification part of IM in System Center Service Manager beta 1.

The main goal of the IM process is to get back to a normal service operation as quickly as possible and to minimize the impact on the business, in other words ensuring that the best possible levels of service quality and availability are maintained. “Normal service operation” is defined within Service Level Agreement (SLA).

 In my test environment I built the following workflow:

Incident templates can be utilized to achieve IM flexibility. Incident templates include common settings for different types of incidents. For example when a service desk receives a call from a user who can´t access a network folder, the service desk operator can then apply the network issue incident template and make sure all the necessary information is collected from the user reporting the incident. The templates also guarantee that incidents are configured with correct owner, category, priority and other related items.

System Center Service Manager has a connector to System Center Configuration Manager that synchronizes hardware information and other relevant information to Service Manager. When a service desk creates an incident and selects which machine the affected user is working from, the service desk can see all information synchronized from Configuration Manager.

In Service Manager there are a number of workflows out of the box and you can also create your own. One of them is Incident Change.

In my test environment I built the following four workflows:

1. One workflow sends e-mail to the affected user when new incidents are created. It is always good for the user to have the incident ID and to know which service desk has begun working on the incident.

2. One workflow sends an e-mail notification to the operator who is configured as “assigned to” in the incident. If it is not the same operator creating the incident who will be working on it, it is good to send a notification.

3. One workflow sends an e-mail notification to the operator who is configured as “assigned to” in the incident. If another operator adds a comment or information to the incident a notification will be sent to the operator who is assigned to the incident.

4. One workflow sends an e-mail notification to both the affected user and the operator who is configured as “assigned to” in the incident.

Service Manager synchronizes information from Active Directory through an AD connector so e-mail addresses and other account information already exists in Service Manager. Here we don’t have to create recipients the same way as we do with subscribers in Operations Manager.

It is reasonably easy to configure incident templates and notifications based on them. There are a couple of scenarios where I could see a need of more detailed criteria parameters. But as this is Service Manager beta 1 I guess we will see a lot more features in the RTM version. I think that the biggest obstacle will not be to how to configure Service Manager but instead how to plan and design all your workflows before you can input them into Service Manager.