Notifying the Affected User When the Analyst Has Updated the Action Log

Notifying the Affected User When the Analyst Has Updated the Action Log

  • Comments 38
  • Likes

Update:  All the discussion on this post led me to create a much better solution called Send Email that ships with the Exchange connector.  I HIGHLY recommend checking that out as a better alternative to this.


  • Awhile back I made a post about how you can send notifications to the Affected User when the analyst clicks on the Request Input from User task.  Another common thing that people ask how to do is to send notifications to the affected user whenever the analyst updates the action log just so the affected user is kept in the loop.  That requires creating a relationship subscription which as we have shown in a previous post is only possible to create directly in XML.

    In the MP XML below I've created a notification subscription that will send a notification to the affected user whenever the action log has an analyst comment added to it.

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






<Name>Action Log Add Relationship Subscription</Name>


<Reference Alias="Console">





<Reference Alias="NotificationsLibrary">





<Reference Alias="WorkItem">





<Reference Alias="ServiceManager.IncidentLibrary">





<Reference Alias="System">





<Reference Alias="IncidentLibrary">





<Reference Alias="Subscriptions">





<Reference Alias="Administration">








<Category ID="Category.ActionLogAddRelationshipSubscriptions.ManagementPack" Value="Console!Microsoft.EnterpriseManagement.ServiceManager.ManagementPack">




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

<Category ID="ActionLogAddRelationshipAffectedUserNotificationTemplate.Category" Target="ActionLogAddRelationshipAffectedUserNotificationTemplate" Value="Administration!ServiceManager.Console.NotificationManagement.NotificationTemplates.Enumeration" />




<Rule ID="ActionLogAddRelationshipSubscriptionRule" Enabled="true" Target="ServiceManager.IncidentLibrary!System.WorkItem.Incident.WorkflowTarget" ConfirmDelivery="true" Remotable="true" Priority="Normal" DiscardLevel="100">



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


<RelationshipSubscription RelType="$MPElement[Name='WorkItem!System.WorkItem.TroubleTicketHasAnalystComment']$" SourceType="$MPElement[Name='WorkItem!System.WorkItem.TroubleTicket']$" TargetType="$MPElement[Name='WorkItem!System.WorkItem.TroubleTicket.AnalystCommentLog']$">

<AddRelationship />








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







<WorkflowParameter Name="InstanceId" Type="guid">$Data/BaseManagedEntityId$</WorkflowParameter>

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



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




<RetryExceptions />











<ObjectTemplate ID="ActionLogAddRelationshipAffectedUserNotificationTemplate" TypeID="NotificationsLibrary!System.Notification.Template.SMTP">

<Property Path="$Context/Property[Type='NotificationsLibrary!System.Notification.Template.SMTP']/Subject$">&lt;1033&gt;Action log entry added to $Context/Property[Type='WorkItem!System.WorkItem']/Id$ &lt;/1033&gt;&lt;2057&gt;Incident ID: [$Context/Property[Type='WorkItem!System.WorkItem']/Id$] has been updated by the analyst&lt;/2057&gt;</Property>

<Property Path="$Context/Property[Type='NotificationsLibrary!System.Notification.Template.SMTP']/Priority$">2</Property>

<Property Path="$Context/Property[Type='NotificationsLibrary!System.Notification.Template.SMTP']/IsBodyHtml$">True</Property>

<Property Path="$Context/Property[Type='NotificationsLibrary!System.Notification.Template']/Content$">




Title: $Context/Property[Type='WorkItem!System.WorkItem']/Title$

Description: $Context/Property[Type='WorkItem!System.WorkItem']/Description$

Created By: $Context/Path[Relationship='WorkItem!System.WorkItemCreatedByUser' TypeConstraint='System!System.User']$?$DisplayName$

&lt;/1033&gt;&lt;2057&gt;Incident Title: $Context/Property[Type='WorkItem!System.WorkItem']/Title$ &amp;lt;br/&amp;gt;

Assigned To: $Context/Path[Relationship='WorkItem!System.WorkItemAssignedToUser' TypeConstraint='System!System.User']$?$DisplayName$?&amp;lt;br/&amp;gt;


Updated action log entry: &amp;lt;br/&amp;gt;





$Context/Path[Relationship='WorkItem!System.WorkItem.TroubleTicketHasAnalystComment' TypeConstraint='WorkItem!System.WorkItem.CommentLog']/Property[Type='WorkItem!System.WorkItem.CommentLog']/Comment$





<Property Path="$Context/Property[Type='NotificationsLibrary!System.Notification.Template']/Encoding$">utf-8</Property>

<Property Path="$Context/Property[Type='NotificationsLibrary!System.Notification.Template']/SeedClass$">System.WorkItem.Incident</Property>

<Property Path="$Context/Property[Type='NotificationsLibrary!System.Notification.Template']/Protocol$">SMTP</Property>




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


<DisplayString ElementID="ActionLogAddRelationshipSubscription">

<Name>Action Log Add Relationship Subscription</Name>


<DisplayString ElementID="ActionLogAddRelationshipSubscriptionRule">

<Name>Action log entry added to action log</Name>


<DisplayString ElementID="ActionLogAddRelationshipAffectedUserNotificationTemplate">

<Name>Notify affected user that action log entry has been added to action log</Name>






Creating relationship subscriptions is actually pretty easy. You just need to follow the pattern above and replace certain configurable parameters with the correct values. I'll explain those here for reference:

First is the Target of the Rule. Unless you know what you are doing, you should probably stick to using a workflow target from among the out of the box list of workflow targets:

Workflow Target Class ID

Workflow Target Class MP












You can get more information on Workflow target from this blog post if you need to do something beyond the above.

Next is to define which RelationshipType you are subscribing to. You can get a list of the relationship type IDs from the database by using the queries provided in this blog post. Each Relationship Type has a Source Class and a Target Class. You can get those from the same blog post using SQL queries.

Next up is to indicate which Related Users you are going to notify. Do this by indicating the relationship type which points from the class that you are notifying about (in this case the Incident class) to a System.Domain.User class. You can get the Relationship Types again using the database query post above.

Last is to indicate which Notification Template you will use. In this case I am using a notification template defined in the same MP.

One last note. You'll see that in this notification template I did something a little fancy. I inserted a insert tag for the Action Log (i.e. TroubleTicketHasAnalystComment relationship type). The relationship between an incident and action log comments is 1:many. So – how do you show that in a notification template? Ideally you would show a list of the action log entries. The same could be true for related configuration items, related work items, etc. In other words anything where there are many items related to the item you are notifying about.

To deal with this we have created a special <Group> tag that can be used in the notification template. When you surround the Insert tag with the Group tag we will iterate through everything in the Group tag and repeat it for each related object.

This is what the Group tag looks like in the notification template properties dialog:


Incident Title: $Context/Property[Type='WorkItem!System.WorkItem']/Title$ <br/>

Assigned To: $Context/Path[Relationship='WorkItem!System.WorkItemAssignedToUser' TypeConstraint='System!System.User']$?$DisplayName$?<br/>


Updated action log entry: <br/>





$Context/Path[Relationship='WorkItem!System.WorkItem.TroubleTicketHasAnalystComment' TypeConstraint='WorkItem!System.WorkItem.CommentLog']/Property[Type='WorkItem!System.WorkItem.CommentLog']/Comment$







And this is what it looks like when sent in HTML.


Incident Title: Test Subject
Assigned To: Aaron James
Updated action log entry:









Note: per this forum thread we had there is a bug in SCSM 2010 which displays the objects in essentially random order. This has been fixed for SP1.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • How far off is SP1?

    I think ideally, comments need the option of sending the comment to the affected user, rather than an all or nothing.

    At the moment I'm trying to work out the best way to get staff to just send an update to the affected user... manual email is all we have so far.

  • SP1 RC - Nov 2010

    SP RTM - Dec 2010

    Agree with you on that one GGP!  I'm working on a solution here...

  • This implementation ignores the 'private' flag on Action Comments.  The 'private' flag is really what giantguineapig is looking for, but unfortunately the flag isn't available on the 'Request User Input' dialog.  Not that it would matter since it is ignored anyways.

    I can make notifications for new incidents work great. I can make notifications for resolved incidents work great as well, the notifications pick up the latest resolution text regardless of how many times the incident has been opened and closed.  But sending notifications for updates is impossible to send and expect the fields to work ask they are decribed in the gui.  I hope sp1 fixes this, but really waiting until sp1 to fix this is absurd.  It would also be nice to be able to send the latest action log comment (and if it is marked private, then don't send an email).

    I can't see a way to fix these things except to create a completely custom form and custom workflow.  I love SCSM, but I can't believe such basic functionality was missed for the RTM.  I see plenty of complaints about this that were clearly posted back during the betas. PLEASE PLEASE PLEASE don't wait until SP1 to fix these issues.

  • Thanks for the info Travis.

    Good point Brian, although I'd probably prefer the reverse, a tickbox to 'notify user of update' which creates a workflow to send that update to the end user.

    I'm also finding it's annoying that you can't send an update with just the last comment, which makes it difficult for escalations etc as well as end user.

    I'm also trying to work out how to make the description window bigger!

  • @GGP -

    As we've discussed offline, I've got something coming in the next couple of days for sending email.  

    You can change the size of the Description textbox using form customization.  Here's a couple of examples of customizing forms:

  • Travis, this is great stuff. I lok forward to any updates you may have in the user update notification front. Curently I use the Has Analyst Comment > Comment method but not only do I get all the updates in the action log, but they are not in chronological order. So the most recent update gets buried in the middle. This is a bit confusing for the user. Keep up the battle and keep us posted on any improvements.

  • @wolverangel - I'm going to provide a better solution to this whole problem in the "resource kit" I announced a little while ago.

    Stay tuned!

  • Travis,

    I'm trying to create a subscription similar to your example above. I want the subscription to run when the action log has been updated, but only when the source of the incident meets specific criteria. I've tried copying the format that SM generates, but it doesn't seem to work with a RelationshipSubscription, only the InstanceSubscription.

    Any ideas?

  • @Tim

    Hi Tim. Unfortunately when you create a relationship subscription like this you can only use the key properties of the objects on the end points of the relationship as criteria.  For example - the key properties for the domain user class are user name + group. You could create a relationship subscription that says - look for 'assigned to user' relationships that are added where the assigned to user object has domain = 'redmond' and user name = 'twright'.  It's not possible to use non-key properties of the objects on the ends of the relationship.

  • @Travis

    First: I believe this is what was discussed in the first reply to the post. Is the default functionality of SM to send out all action log entries, rather than the latest one? Is it possible to target the one that initiated the workflow?

    Second: Dang. In order to get this functionality (and only the most recent comment), would I be required to write a custom activity, and create the workflow in the authoring tool?

  • @Tim

    If you put a Group tag around it will send all of them.  If you don't it will send a random one.  In SP1 we have fixed it so that if you are not using the Group tag we will send only the most recently added/modified.  If you are using the Group tag we will order them by last modified/added time.

    I've got a better solution coming for all of this in the "resource kit" I announced back here:

    I think you'll be able to combine that solution with some other stuff to achieve what you need to do.  If you want to follow up offline with me we can work out some of the specifics.  scsmbeta [at] live [dot] com.

  • @Travis

    If, in my criteria, I'm only able to target the properties of the two classes that make up the relationship, what is the lookup running against? Does it run a lookup against all of the entries, a random one, or the most recent?

    Example (pseudo):






    <Property>TroubleTicketHasAnalystComment - EnteredBy</Property>



    Wouldn't it run against the most recent one entered?

  • @Tim -

    OK this is going to get a little complicated so please bear with me...  there are different types of relationship subscriptions you could do:

    1) Subscribe to an instance of a relationship being updated, meaning that some property on the relationship was updated.  We dont have support for this, but that's OK because there are only maybe one or two relationship types that even have properties defined on them.

    2) Subscribe to an object using criteria that looks at a related object.  For example - any incident that is updated where the assigned to user has the domain property = 'foo'.  This is supported but only over certain relationship types.  This isnt really what you are looking for since you only want to be notified when the relationship instance is *added* between an incident and a new actio log entry.  That's different than saying - whenever an incident is updated (regardless of what is updated) and it is related to an (any) action log entry that has the word 'foo' in the title.

    3) Subscribe to the add/remove of a relationship instance of a certain relationship type.  This is the one you want.  Basically it says 'whenever a relationship instance is created of the type 'Incident Related to Action Log' trigger the notification or the workflow.  For this type of subscription you can only specify what type of relationship type you are looking for and you can use *key* property values of objects on the end of the relationship type.  For example - you could say 'Notify me anytime the relationship of relationship type 'Incident Assigned to User' is added and the related assigned user has the domain = 'foo' and the username = 'bar'.  Domain and Username are compound key properties of the user class so they can be used in the criteria.  You couldn't for example use the user's office number as part of the criteria since office number isn't a key property of the user class.

    So - assuming you are trying to do a #3 type of subscription what you are getting is the exact moment in time that either a relationship instance is *added* or *removed* from between two objects.  In some cases like when the assigned to user changes that is actually first a removal of a relationship instance and the adding of another relationship instance.  When you are adding entries to the action log that is just creating new relationship instances.

    Hope that makes sense.

  • @Travis

    Thanks for keeping up with the replies.

    I think your explanation makes perfect sense. I'm still confident that I should be able to do what I want. In your example about Incident Assigned To User, couldn't you look at the key properties of an Incident, since the Incident is 1 end of the relationship, and the Assigned to User is the other?

    The type of relationship that I'm subscribing to is System.WorkItem.TroubleTicketHasAnalystComment. I believe the 2 ends of this relationship SystemWorkItem.TroubleTicket & System.WorkItem.TroubleTicket.AnalystCommentLog. So, couldn't I look at a property 'Source' property SystemWorkItem.TroubleTicket, and the 'EnteredBy' of System.WorkItem.TroubleTicket.AnalystCommentLog? I'm guessing no, because our conversation has gone this far.

    Do I have the idea of the end points of a relationship mixed up?

  • I'm finding that the easiest way to see what properties exist in each class, is to use the SM Console > Templates > Insert properties into the email body.

    The 'TroubleTicket' only has Closed Date, Impact, Priority, Resolved Date, and Urgency. My 'Source' is located in 'Incident'.

    Is there a relationship that pairs ActionLog entries with Incidents? Can this relationship only be 'achieved' by creating a custom workflow activity?