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.
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="http://www.w3.org/2001/XMLSchema" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<Name>Action Log Add Relationship Subscription</Name>
<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']$">
<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">
<ObjectTemplate ID="ActionLogAddRelationshipAffectedUserNotificationTemplate" TypeID="NotificationsLibrary!System.Notification.Template.SMTP">
<Property Path="$Context/Property[Type='NotificationsLibrary!System.Notification.Template.SMTP']/Subject$"><1033>Action log entry added to $Context/Property[Type='WorkItem!System.WorkItem']/Id$ </1033><2057>Incident ID: [$Context/Property[Type='WorkItem!System.WorkItem']/Id$] has been updated by the analyst</2057></Property>
Created By: $Context/Path[Relationship='WorkItem!System.WorkItemCreatedByUser' TypeConstraint='System!System.User']$?$DisplayName$
</1033><2057>Incident Title: $Context/Property[Type='WorkItem!System.WorkItem']/Title$ &lt;br/&gt;
Assigned To: $Context/Path[Relationship='WorkItem!System.WorkItemAssignedToUser' TypeConstraint='System!System.User']$?$DisplayName$?&lt;br/&gt;
Updated action log entry: &lt;br/&gt;
<LanguagePack ID="ENU" IsDefault="true">
<Name>Action log entry added to action log</Name>
<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/>
And this is what it looks like when sent in HTML.
Incident Title: Test Subject Assigned To: Aaron JamesUpdated 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.
1) There are different types of action log entries which are each defined by a different class and they all dervice from a common base class. The base class is System.WorkItem.CommentLog. The derived classes are:
Each of these classes is related to the System.WorkItem.Incident class over a relationship type
System.WorkItem.TroubleTicket.UserCommentLog is System.WorkItem.TroubleTicketHasUserComment
System.WorkItem.TroubleTicket.AuditCommentLog is System.WorkItem.TroubleTicketHasAuditComment
System.WorkItem.TroubleTicket.AnalystCommentLog is System.WorkItem.TroubleTicketHasAnalystComment
2) The properties defined on the TroubleTicket class and the relationships between CommentLog classes and TroubleTicket are inherited to the two work item classes that derive from TroubleTicket - Incident and Problem.
Does that help? I don't think I understand the scenario you are trying to achieve.
My last post came through as Anonymous? I've probably made this more difficult than it needs to be.
I'm trying to achieve 2 things. 1) Get a better understanding of relationships 2) Find a way to kick my workflow off when the source of the incident is X and the action log entry was not made by X.
It seems my best option is to create a custom workflow activity. I will target that workflow to run when an action log entry has been created. From there, I can get the Incident as an object in the WF, check it's properties, and do whatever I need to do.
@Anonymous (aka "Tim") :)
Yep, that's your best and only option right now. We are making some improvements to the subscription infrastructure but since this is the first time I have heard of a requirement like this it's not high on the priority list vs. some other things so it probably isnt going to happen in the next release.
Weird that you keep seeing Anonymous. I see my name. I must have posted too many times on this post :)
Thanks for the follow up. I have this requirement because I have a service that is creating incidents on behalf of a 3rd party, and I need to send notifications back up to them when only their incidents are updated.
I see. You'll probably be able to use this new solution I'm coming out with in the "resource kit" to handle this better.
Yes, I'm back, but with a different situation. I'm trying to create the last piece of the 'Request User Input' roundabout, and that is notifying the Assigned Analyst when the Action Log is updated by the Affected User. Is this possible? I don't think it is, but I want to verify before I roll a custom workflow activity.
To send to the AssignedToUser, I can use
<WorkflowArrayParameter Name="UserRelationshipIdList" Type="guid">
However, I need Criteria to look at the EnteredBy property of the System.Workitem.TroubleTicket.AnalystCommentLog. Am I able to use some sort of $MPElement[Name='WorkItem!System.WorkItemAffectedUser']/$DisplayName to use as the lookup in the criteria for who entered the comment?
I too am trying to modify this so that when the end user updates their incident from the portal... the analyst gets notified. I thought since it adds an event to the action log that is very similiar to the analyst event in the action log that I could just change up the variable a bit. Alas, I was unable to get it working successfully. Could you provide some help with how to get a notification when someone updates their incident from the web portal? We have issues with our analysts not finding out that someone updated their request.
Is there a way to get the last action log entry in the email.
@Umang - no, not right now. Check out the Send Email solution that comes with the Exchange connector as an alternative solution to this problem.
I have imported this MP with no modifications. When I add an action log entry as the Assigned To user either by email (via the Exchange Connector) or through the console the workflow doesn't ever appear to trigger and the affected user never receives an email.
Am I missing something?
Are there any clues in the Operations Manager event log on the SCSM management server?
Actually, I got it working. Not sure how though!
One more thing. You mentioned that if you exclude the <Group> tag it should only show the most recent comment. I've removed the tag but the $Context/Path[Relationship='WorkItem!System.WorkItem.TroubleTicketHasAnalystComment' TypeConstraint='WorkItem!System.WorkItem.CommentLog']/Property[Type='WorkItem!System.WorkItem.CommentLog']/Comment$ still iterates through all of the analyst comments.
Did that change actually make it into SP1?
Is it possible to notify affected user only when action log entry added with PRIVATE checkbox NO selected ?
@Kirill - no sorry that's not possible.
I have posted MP in here: