The Status of an Incident in Service Manager is triggered on a certain action. It can be needed that more granular Incident Status levels are required for your environment. In this post I’m going to explain how we can extend the Incident status levels and how we can automate Status level update with a workflow when certain fields in the Incident Form are updated.
First, look at the default list in the Service Manager console – Library | Lists | Incident Status
As an example, the default list is extended with the following Status levels as sub status of the Active status: (Create a mgmt pack to store the console configuration)
- Listed: is the default status in this example
- Assigned: When the Incident is “assigned” (Assigned to field)
- In progress: When the Incident has an “Owner” (Primary Owner field)
Once the status levels are defined, one Incident Template must be created for each status level that is added to the list.
Create the Incident Status Templates:
In the Service Manager console – Library | Templates | Create Template
- Store the configuration is the just created mgmt pack.
- The “Status” field is visible now and status can be set for the template.
- Repeat this procedure for the “In progress” and “listed” status.
Create the status update xml file:
The creation of the xml file is more or less the same as explained in following blog post: Custom notification workflow on incident assignment or re-assignment
- Use your own naming in order to recognize that function of the mgmt pack.
- The “Here is some explanation of some of the sections of the Management pack to better understand the “how” is the information where this mgmt is based on.
- All info explained in this section can be used for this mgmt pack.
- The Monitoring Section of the xml needs to be changed in order to get this functionality in SCSM.
Monitoring section of the XML file:
In order to start updating the monitoring section of the xml file it is important to gather the info of the fields that trigger a status update. For certain Incident Form fields it is possible to accomplish the goal by editing the rules in the ‘Incident Event Workflow’. The wizard there only supports certain subscription criteria:
- If a property field of the System.WorkItem.Incident triggers a status update, then the console can be used.
- If relationship properties triggers an update, then xml coding is required.
- SCSM product team is busy creating a complete model diagram. This will be your main source for finding this information. (I will update this post when this info is published.)
- In this example the AssignedToUser property triggers the “Assigned” status of the Incident. The AssignedToUser property is and example of the relationship properties and needs xml editing.
As explained in the blog post above, in the Monitoring section we define the Rules. Each rule in generally includes a DataSource and WriteAction section.
- DataSource define discovery of the instances based on certain criteria
- In this case we want to discover any incident for which the “Assigned to” user is changed
- “Assigned To” user is a relationship on the Incident – So whenever the assignment is changed the existing relationship is deleted and a new relationship is added
- The criteria below discovers all instances of incidents for which a “AssignedTo” Relationship was added
- WriteAction defines the “action” you want to perform on each instance that was discovered by the rule
The following xml code creates a relationship subscription for the AssignedToUser relationship on the Incident.
<DataSource ID="DS" TypeID="SystemCenter1!Microsoft.SystemCenter.CmdbInstanceSubscription.DataSourceModule">
<RelationshipSubscription RelType="$MPElement[Name=’WorkItem!System.WorkItemAssignedToUser’]$" SourceType="$MPElement[Name=’CustomSystem_WorkItem_Incident_Library!System.WorkItem.Incident’]$" TargetType="$MPElement[Name=’System!System.Domain.User’]$">
For the other status (In progress) in the example used for this blog the RelationshipSubscription needs to be modified. PrimaryOwner is the property that triggers the status update.
<RelationshipSubscription RelType="$MPElement[Name=’WorkItem!System.WorkItemPrimaryOwner’]$" SourceType="$MPElement[Name=’CustomSystem_WorkItem_Incident_Library!System.WorkItem.Incident’]$" TargetType="$MPElement[Name=’System!System.Domain.User’]$">
The following example updates the Incident status by applying the Incident Template. So, the same xml code can be used for both status updates, only the Template GUID must be changed.
To find the Template GUID:
- In order to get the GUID for your own template from the DB you can use a simple query
- "select Objecttemplateid from ObjectTemplate where ObjectTemplateName='< Template Name here >’
<WriteAction ID="WA" TypeID="SystemCenter1!Microsoft.EnterpriseManagement.SystemCenter.Subscription.WindowsWorkflowTaskWriteAction">
<WorkflowArrayParameter Name="InstanceIds" Type="guid">
<WorkflowParameter Name="IncidentTemplate" Type="guid">8bf7765f-f372-debb-f924-e1ebd2ec7ac6</WorkflowParameter>
<WorkflowParameter Name="NotificationRulesEnabled" Type="boolean">False</WorkflowParameter>
In this way we can create a complete mgmt pack that takes control over the Incident Status updates. (like the default defined Incident Status entries like Active, Closed or Resolved)
I will post the complete xml file that can be used as an example to create your own. The xml file includes the workflows to update the three custom status levels.
Have fun with it!
Kurt Van Hoecke