Note: this blog post is relative to System Center 2012 – Service Manager (or later) only.
This is a guest blog post from one of our community experts – Greg Wojkun. Thanks for sharing with us Greg!
Our change request process requires CR owners to supply details of their change request in the change request description data property on the CR form. The CR owner must also apply the correct Review Activities and Manual Activities related to the CR and supply more or less the same details in the description field of the MA and/or RA. As the SCSM Admin, I often get this question from end users: Why do I need to duplicate my efforts of writing the CR description and also writing more or less the same description the MA or RA description field? My response to them is simple: We want to ensure the Reviewer(s) and/or Activity Implementers have all the basic information they need when they receive the workflow email to either approve or complete the activity from the email (using the exchange connector). In SCSM 2010, it was not possible to carry the CR data properties into MA and RA email templates. In 2012, this is possible. But during my quest to do this, it was not explicitly easy to do so. In working with Travis, I have figured out how to make this work and I would like to share that experience for SCSM users out there who may have a similar desire from their end users.
First, we need to understand the relationship structure between the MA/RA and the CR. We all know the MA/RA displays the parent ID as such:
But what is the actual “Relationship class” that SCSM uses to link these together in a family? We need to identify this in the history section of the MA/RA. As we can see from the below, SCSM uses “Contains Activity” as the relationship between the MA/RA and the Parent CR:
Having now understood this, we can use this information to link data properties of the Parent CR into the MA/RA. So lets now look at the email template engine for MA/RA class emails. As you can see in the below, we have numerous relationship types to choose from. Here is where it may be confusing from an administrative perspective on trying to pull CR data properties into an MA/RA email template. You can see we have the following data properties to choose from that, from a literal perspective, seem like the possible ones to use:
I have circled one in red in particular. Common sense would lead you to select this one. However, this is not the correct data property to use. Going back to our illustration earlier, we have learned that “Contains Activity” is the Correct data property to use as we discovered this is what SCSM uses for the relationship between the MA/RA and the CR.
Note: At this moment, I cant explain why there are Two (2) Contains Activity and other multiple relationships (e.g. 2 - Depends on work Item). For this example, use the top most “Contains Activity” Travis: this is because a review activity can be contained by another work item and it can contain other work items:
So as we choose the Contains Activity Relationship, we can see that there are no data properties to choose from for “Change Request”. I have requested the SCSM engineering team to put those data properties in there for the next release. But until that happens, we are limited to solely the “Work Item” data properties which are as follows:
So lets re-cap what we have discovered here. We determined the relationship type between MA/RA and CR is “Contains Activity”. We discovered this by reviewing the history section of the MA/RA. Then we launch the email template engine and begin building our MA/RA email template and determine which “Contains Activity” – Work Item properties we want to capture from the CR. Again, Specific CR properties (such as “Change Reason”) are not available to select. Thus we are limited to Work Item properties. In my example, I have chosen the following Work Item properties under the “Contains Activity” relationship:
So we build the template as follows. This is my example only. You may want to be more creative in your template. You will note some code highlighted in yellow: SeedRole=’Target’. You must insert this code in the following locations each time you include a Contains Activity data property. After the relationship class and before the “Type Constraint” Line. Travis advised me of this when I was working with him on finding a solution for this. Perhaps this may be fixed in the next release, but I will defer to Travis on that. In any instance, you must insert that code as follows. This is what allows the CR properties to be brought into the MA/RA email templates.
Then, if you have not already done so, you must configure your MA/RA workflow based on rules. Something like: When MA/RA status changes from “Pending” OR Blank to “In – Progress”. Once you have done that and linked your new template to the workflow, you will be ready to go.
Your end result, will be an email as follows for RAs/MAs. This allows end users creating CRs to not have to duplicate their efforts of providing the CR details in two locations. It also helps approvers (reviewers) get the CR data they need directly in the email. If you want to be more creative, you can also include a hyperlink to the End User Portal directly to the CR. You can, of course, easily use the MA/RA data properties in your template also to capture even more details. The illustration below is intended to show how CR data properties can be used in MA/RA email templates.
Any further information on how this would work to reference the parent SR/CR in an activity if it's contained within a PA/SA? Thanks!
1. Is it possible to include the SM Portal Change Request URL in the Review Activity and Manual Activity e-mail template ?
2. Is it possible to add the Reviewer's display name into the Review Activity e-mail template ?
Any advice on this would be appreciated; Following this example just results in new incident tickets being raised instead of the RA being approved/rejected. I have checked the parsing keyword is indeed [Approved] (or [Rejected]).
It seems that you are not using Exchange connector.
I am using the Exchange Connector as this is what is being used to create the incidents. In order to mark a review activity as approved, what should be in the subject and body of the email? (to check that we are doing this right)
The subject needs to contain the work item ID in square brackets - e.g. [RA1234]
The body of the email needs to contain a configurable keyword. The keyword that the wizard suggests is Approved in square brackets - e.g. [Approved].. You can use whatever you want though. Just make sure you using something that wouldn't normally appear in an email message like simply 'Approved' to avoid unintentional approvals. For example 'I do not approve this'. :)
OK, I see. Subject should contain RA Id in bracket [RA12345]. Body should contain keyword that is configured in Exchange connector (including bracket as well if configured in the connector).
It works fine in our environment.
Thanks guys, was the square brackets in the subject that was missing, clearly I can't read and copy text correctly haha :P
This looks great and gets me about 50% where I need to be. I lso
Sorry for the half post.. Tripped up on my iPad. I also need to include the CR information on review and manual activities when they are contained within a parallel activity.... Has anyone figured this out?
We don't use parallel activities much so we did a workaround using Orchestrator. There are a few examples on my blog:
I'm looking to do this via PowerShell in the future to improve performance
Just wanted to add that it is possible to insert Change Request specific fields (such as Change Reason, Implementation Plan, etc.) in the notifications, but not directly via GUI.
You can't insert those properties by using the insert button in the notification template Editor, you'd have to type / paste them manually in instead.
To Access those properties you can use the following Schema
<b>Reason:</b>$Context/Path[Relationship='CustomSystem_WorkItem_Activity_Library!System.WorkItemContainsActivity' SeedRole='Target' TypeConstraint='CustomSystem_WorkItem_ChangeRequest_Library!System.WorkItem.ChangeRequest']/Property[Type='CustomSystem_WorkItem_ChangeRequest_Library!System.WorkItem.ChangeRequest']/Reason$
You just have to ensure that your Management pack with the notifications contains a reference to the System.WorkItem.ChangeRequest.Library. If it already does, use your reference alias and replace the "'CustomSystem_WorkItem_ChangeRequest_Library" alias from my example with yours. If you don't have a reference set to this MP just add the following reference to your MP references section:
With this approach it's possible to subscribe / insert any CR specific properties to your activity notifications.
Hope that helps.
I have same issue like as comment that sent by "Wyatt Wong"
2. Is it possible to add the Requester or Reviewer's display name into the Review Activity e-mail template ?
I still can't get mine to work.. I have the correct reference in my MP but when I try to type in the substitution string or copy/paste, etc.. the notification email just prints the sub string.
Nobody can help me ?