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.
Big thanks for this post. I'm gonna try this out. Will be of great help if it works.
@ Dries: Please let us know how it goes!
Not running in SCSM 2012 RTM. I get the message with the code
WI descr $Context/Path[Relationship='CoreActivity!System.WorkItemContainsActivity' SeedRole=’Target' TypeConstraint='WorkItem!System.WorkItem']/Property[Type='WorkItem!System.WorkItem']/Title$
Is there more information in the error message you are getting? did you type in that string $...$?
@Travis Wright MSFT
I have created a e-mail notification for manual activity. I get an email with this code.
did you type in that string $...$? Yes
Is this happening on all the data properties you try to insert in your email template? Or just the one with SeedRole='Target' added to the data property code? I would recommend using the insert button always when creating email templates. Never cut and paste from other email templates. Using out of the box unsealed MPs and your own custom MPs results in different code for each.
Greg thank you!
It worked. Just do not know what was the problem.
Great post - one item I can't get working is where you have integrated this into the Exchange Connector.
The email is sent to the implementer but when they can click on "Mark as complete", the subject of the email to send to the exchange connector is just the string:
The mailto doesn't seem to do parameter \ variable substitution of the workitem ID but, because it is enclosed in the " ", is just evaluated as a string. I have tried a number of options around
<a href="mailto:firstname.lastname@example.org?subject="+[$Context/Property[$Context/Property[Type='WorkItem!System.WorkItem']/Id$]"+&body=[Completed]">Completed</a> but these just return an empty subject.
Your data property context is not coded correctly. See mine below... Make sure always to instert the data property and not cut and paste it from other locations/templates, etc.
If see mine below, you will see the difference in the code
Yours: <a href="mailto:email@example.com?subject=[$Context/Property[$Context/Property[Type='WorkItem!System.WorkItem']/Id$]&body=[Completed]">Completed</a>
Mine: To expedite, click <a href="mailto:SomeEmail@SomeDomain.com?subject=[$Context/Property[Type='WorkItem!System.WorkItem']/Id$]&body=[Completed]"><b>Mark as Complete</b></a> then send.<br>
Not sure what I did - I have learnt not to copy and paste the template info but perhaps my brain went awol for a while or perhaps I just inserted the wrong data. Thanks for getting back to us quickly with confirmation that it does work and I can confirm that having removed the line and reinserted, it works great for me.
I have noticed that this doesn't work when you have parallel activities that contain the manual \ review activities.
In these cases the parallel activity appears to be the parent of the Change Request and the associated Manual and Review Activities which fundamentally breaks this process.
Have you come across this before? And wondered if you had figured out a workaround?
Hmm... good catch! I havent tested this solution using parallel activities, but the behavior you are mentioning makes sense. If I understand correctly, the above blog is not working when you have a MA or RA under a Parallel Activity? You may need to play around with choosing a few different relationships in the email engine data properties selection. I'll play around with this when I have some time so see if I can figure out a solution.
Greg/Travis, I noticed it was mentioned in this thread that code will be different if using custom MP which I am using. Here is the output I'm seeing in my service request e-mail notification template for 'Parent ID'...
The following manual activity has been updated:
Manual Activity ID: MA485
Parent Request ID: $Context/Path[Relationship='CustomSystem_WorkItem_Activity_Library!System.WorkItemContainsActivity' SeedRole=’Target’ TypeConstraint='CustomSystem_WorkItem_Library!System.WorkItem']/Property[Type='CustomSystem_WorkItem_Library!System.WorkItem']/Id$
Title: User Move Request
Description: Move user and all computer equipment to a new location
What changes should I make to my service request e-mail notification template if I'm saving my e-mail notification templates to my own custom management pack?
Apprecaite your help!!
I havent tested this with the Service Request Class (Only CR Class), but in theory it should work the same. I checked out your property code and it matches mine. Hmmm. Is the only Parent property you call in the email template just the work Item ID? Or is the description, etc coming from the parent also?
@ Graham Davies, or anyone else who can answer...
were you able to figure how this will work is RA are in a PA?