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.