Custom notification workflow on incident assignement or re-assignment

  • Comments 102
  • Likes

There are couple important contributions from our users I wanted highlight

  1. There were quite a few requests to Notify additional recipients (e.g. Affected User / Primary Owner) on the assignment changes.  Andrew France has written the MP that does this.  Here is the MP
  2. Another useful blog post that has been created by one of SCSM admirers on this topic that users have found helpful.

As always ensure that the MP is what you need before importing it.


Thanks for your contributions.  Keep them coming! It keeps the community vibrant and alive!

------------ original post ------

This blog posts demonstrates how to configure a notification workflow in Service Manager that sends out notifications on reassignment of the incident.

I am not going to go through details on management pack mechanics as they are already available here.


Steps for creating this custom workflow:

1.       Create a new XML file – Name it: ServiceManager.IncidentAssignmentChanges.Notification

2.       Copy and paste the  complete XML provided at the end of the post

3.       Change the version number in the file with version to match your build

a.       i.e. if you are using Beta 2 then build number is 5229, If you are using Beta 2 update, then you do not need to change the build number it is already 5244

b.      The version string that you need to change for all references is shown below:

                                                               i.      <Version>7.0.5244.0</Version>

c.       You can look up the build on Service Manager Help-> About

4.       Save the File as ServiceManager.IncidentAssignmentChanges.Notification.xml

5.       Last Step is to Import the management pack

a.       Open Service Manager Console

b.      Go to Administration -> Management Packs

c.       Click on “Import” in the task pane

d.      ClickAdd” in the MP Import screen

e.      Select the management pack file that you created

f.        Click Import

g.       If you get errors, please check again your MP against the XML I have provided.

                                                               i.      Also check the version information – Did you change the build number to match your build.

6.       Verification

a.       Open Service Manager Console

b.      Go to Administration->Workflows->Status

c.       You should see “Incident Assignment Notification” in the view pane as shown below


Here is some explanation of some of the sections of the Management pack to better understand the “how”

1.       Manifest Section

a.       The references section lists the dependencies for this management pack

b.      Aliases defined for these references just makes it easier to refer to these management packs in the subsequent sections

2.       Categories section

a.       This enables the Workflow to appear in the Service Manager Console UI (Administration->Workflow->Status node)

b.      This allows you to either enable or disable the workflow from the Console UI, thus avoiding having to go and edit (or delete) the management pack, each time you want to disable the workflow

3.       Monitoring Section

a.       In the Monitoring section we define the Rules.  Each rule is generally comprised of a DataSource and WriteAction

b.      DataSource define discovery of the instances based on certain criteria

                                                               i.      In this case we want to discover any incident for which the “Assigned to” user is changed

                                                             ii.      “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

                                                            iii.      The criteria below discovers all instances of incidents for which a “AssignedTo” Relationship was added

c.       WriteAction defines the “action” you want to perform on each instance that was discovered by the rule

                                                               i.      Write Action is generally associated with an Activity/Task (generally a WinWF activity).

                                                             ii.      In this case we are re-using an activity that comes with Incident Event Workflow

                                                            iii.      Note:  This is not a published activity in our Authoring library, so the parameters potentially could change in future

<AssemblyName>Microsoft.EnterpriseManagement.ServiceManager.Incident.Workflows</AssemblyName>           <WorkflowTypeName>Microsoft.EnterpriseManagement.ServiceManager.Incident.Workflows.AutomaticIncidentChangeWorkflow</WorkflowTypeName>


                                                           iv.       The activity takes the “Relationship GUID” for the “Assigned To” relationship and a “notification template GUID” as parameters.

                                                             v.      Do not change the “Relationship GUID”

                  <WorkflowArrayParameter Name="UserAliasOrRelationships" Type="string">



                                                           vi.      You can replace the Template GUID with your own template GUID, if you have one created.

                  <WorkflowArrayParameter Name="NotificationTemplates" Type="guid">



        • In order to get the GUID for your own template from the DB you can use a simple query
        • Here is the one I used to get the GUID for the template that I used

"select Objecttemplateid from ObjectTemplate where ObjectTemplateName='AssignedToUserNotificationTemplate'

4.       Language Pack section:

a.       This enables display of user friendly names in the UI.

b.      You should also review the blog for details regarding localizing the UI.



5.       Complete XML that you can just cut and paste in your file

·         Please note that this is for build 5244, (that is the latest Public Beta 2 bits that were refreshed)

·         You should change the build number to the appropriate build number (5229 for Beta 2, 5244 for Beta 2 update)

<ManagementPack ContentReadable="true" SchemaVersion="1.1" OriginalSchemaVersion="1.1" xmlns:xsd="" xmlns:xsl="">






    <Name>Incident Assignment Changes Notification Workflow</Name>


      <Reference Alias="WorkItem">





      <Reference Alias="Incident">





      <Reference Alias="CoreIncident">





      <Reference Alias="SystemCenter">





      <Reference Alias="SystemCenter1">





      <Reference Alias="Administration">





      <Reference Alias="System">








    <Category ID="IncidentConfigurationMPSolutionCategory" Value="Incident!Microsoft.EnterpriseManagement.ServiceManager.ManagementPack.Solution.IncidentManagement">




      <Category ID="Category.IncidentAssignmentChanges" Target="IncidentAssignmentChanges" Value="Administration!Microsoft.EnterpriseManagement.ServiceManager.Rules.WorkflowSubscriptions" />





      <Rule ID="IncidentAssignmentChanges" Enabled="true" Target="SystemCenter!Microsoft.SystemCenter.SubscriptionWorkflowTarget" ConfirmDelivery="false" Remotable="true" Priority="Normal" DiscardLevel="100">



          <DataSource ID="DS" TypeID="SystemCenter1!Microsoft.SystemCenter.CmdbInstanceSubscription.DataSourceModule">


              <RelationshipSubscription RelType="$MPElement[Name='WorkItem!System.WorkItemAssignedToUser']$" SourceType="$MPElement[Name='CoreIncident!System.WorkItem.Incident']$" TargetType="$MPElement[Name='System!System.Domain.User']$">










          <WriteAction ID="WA" TypeID="SystemCenter1!Microsoft.EnterpriseManagement.SystemCenter.Subscription.WindowsWorkflowTaskWriteAction">







                  <WorkflowArrayParameter Name="InstanceIds" Type="guid">



                  <WorkflowParameter Name="NotificationRulesEnabled" Type="boolean">True</WorkflowParameter>

                  <WorkflowArrayParameter Name="NotificationTemplates" Type="guid">



                  <WorkflowArrayParameter Name="UserAliasOrRelationships" Type="string">




                <RetryExceptions />












    <LanguagePack ID="ENU" IsDefault="true">


        <DisplayString ElementID="ServiceManager.IncidentAssignmentChanges.Notification">

          <Name>Service Manager Incident Assignment Changes Notification Workflow</Name>

          <Description>Service Manager Incident Assignement Changes Workflow</Description>


        <DisplayString ElementID="IncidentAssignmentChanges">

          <Name>Incident Assignement Notification</Name>






Custom notification workflow on incident assignement or re-assignment

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Hi,

    I have found some problems with this Workflow: it send me the same email all the time when I assign a case to me, or when I set resolved a case, or when I set closed a case.

    This workflow supposed to send notification only upon any change in the "Assigned to" field.

    But is still sends me the same notification when I just want to set the incident to Resolved, or Closed!

    Am I doing something wrong?

  • Hi Dan,

    Please check if you have another workflow setup, either in Administrations->Subscriptions or Administration->Workflows->Incident Event Workflow.



  • Also there was a bug in Beta 2 - it sent a notification out regardless of which relationship changed.

    I believe when you resolve the incident, it sets the "Resolve By" user, essentially adding another relationship.  That's the reason you could be getting notification.

    This has been fixed in RC.

  • Thanks! I was a little baffled that something like this couldn't be set up in the subscription wizard. This custom MP works in the RTM.

  • Thanks for pointing the error out.  I have fixed it.

  • Ketan,

    Found another error. This line:

    <Description>Service Manager Incident Assignement Changes Workflow</Description>

    has misspelled "Assign_e_ment". Just needs the extraneous "e" removed.

    Different question: If we wanted to use a different template than the default do we just change this line:

                     <WorkflowArrayParameter Name="NotificationTemplates" Type="guid">



    And if so, how do we find the GUID of the template we want to use?

  • The GUID of the template is stored in the MP where the template is defined.  You can create your own template in Admin->Notifications->Templates and store in your MP.  Open the MP in notepad or Visual Studio or IE and lookup the GUID.

  • I had some trouble with two emails being sent, i increased maximum running time to 7200 and change retry delay to 0.

  • Hi,

    I'm trying to adapt this to do something similar. I want to send a notification to the affected user when the primary owner is assigned or re-assigned.

    I'm not a programmer so could someone help to point me towards what I need to change?

    I'd really appreciate it!


  • Hi guys, does this work with the 7.0.5826.0 ?

    I did a find replace of 7.0.5244.0 with 7.0.5826.0 and I am getting the error "Some management packs in the list are not valid".

    Any tips would be greatly appreciated.

  • I can't find my custom notification's GUID in the database or XML... there is a ObjectTemplate ID "Template_8bd2d848f3d74cf697d052fa47a37946" and the TypeID is "CustomSystem_Notifications_Library!System.Notification.Template.SMTP"

    Do all email templates have a GUID? If it's not in the ObjectTemplate database and XML, where would I find it?

  • There were couple questions about using a different template.  If you define a notification template in the MP, you can open up the MP you should see something like: <Templates>

       <ObjectTemplate ID="Template_9ce56e2013dd4a28a6d207cde13e65a5" TypeID="CustomSystem_Notifications_Library!System.Notification.Template.SMTP">

    The GUID for the template is Template_9ce56e2013dd4a28a6d207cde13e65a5.  This you can replace in  

    <WorkflowArrayParameter Name="NotificationTemplates" Type="guid">



    and it should look like:

    <WorkflowArrayParameter Name="NotificationTemplates" Type="guid">


  • Is there a way to have this workflow send multiple emails? For example, I obviously want to have the user being assigned the ticket to get notified, since they need to know to work on the ticket. This workflow is perfect for that. But what if I also want to have the affected user of the ticket notified that it's been assigned to someone?

    Also - is there a reason that this sort of functionality wasn't included in the RTM of the product? Having all the workflows require a very specific trigger before they're activated has led to people working up lots of goofy conditions for workflows, like, "Do this if <incident category that's required during incident creation> is not Null" - which is obviously always the case. Why can't you just have a workflow kick off when something happens, regardless of what the properties of the ticket or of that "something" are, and without making up an "always true" condition as a trigger?



  • You can add multiple notifications for this condition by duplicate the write action and change the GUID for UserAliasORRelationsShips and if you want to use a different notification template then you need to change the GUID for that.

                     <WorkflowArrayParameter Name="UserAliasOrRelationships" Type="string">




    You can actually create workflows from the UI, Administration->Workflows->configuration and Incident event Workflow.  It's just that we don't support all the rich subscriptions through UI.  This is something we are planning to address in our next release.

  • Ketan,

    Thanks, I'll give that a whirl.

    I know I can create workflows within the UI - I guess maybe I'm just missing something. Is it possible to create an workflow for incident creation, leave the "Specify Event Criteria" portion of the "Add Incident Event Workflow" wizard blank, and have the workflow run every time an incident is created? Or would the total absense of any event criteria mean that the workflow would never run?