HEALTH WARNING: Be very careful cutting and pasting anything with quotes from here, other blog posts, word docs or emails as you may end up with an invalid quote in your notification template, preventing an email from being sent out at all.

There are some blogs out there on this (Thanks Travis Smile), but I struggled to find anything relating specifically to parent SRs which is one of the most common elements I find my customers want to include details from, when triggering a notification of a child activity going to in progress.  And some of my customers have some cool customized SRs for purchase requests / new hire / employee termination process etc. and they want to include those custom properties from the parent SR (that were populated via prompts on the portal) in their activity notifications, and I found nothing on how to do that.

For example, lets say you have a new hire SR as described in my other post and then as part of the approval process, you want a notification to go out to the new employee’s manager, and include some specific properties from your custom SR class, to aid the hiring manager in approving the activity before Orchestrator goes off and does its various magic to create the user with the specified properties.

Before we continue, an alternative way to achieve this is to use orchestrator to put those entered values into a commonly available field (like title or description) and then in your SCSM notification template, just add Title or description.   I’ve seen some customers use approaches like this to parse the user inputs (entered via request offering prompts in the portal) into the title or description.

However the focus of this blog is to explain how you can insert the values directly into a notification template.

We will focus on SR for now and getting the data from a parent SR into a child manual / review activity notification.

NOTE: Remember the notification template will be based off Manual Activity or Review Activity, because the subscription we will later create will trigger off a manual / review status changing from does not equals ‘In Progress’ changing to equals ‘In Progress’.

First things first is figuring out the relationship you need to use. This is best determined from the history tab of the child activity.

So for example if I look at a child manual activity within an SR, we can see the name of the relationship that associates the activity we’re looking at, to the parent SR is called ‘Contains Activity’

image

This helps us when we come to create the notification template in terms of picking the relationship as it narrows it down to two possibilities (not needed that second one to date so not sure what it is for Smile ) :

image

NOTE: Keep reading on after the next paragraph as there’s a second step required to get this working Smile 

Once we pick the top ‘contains activity’ (it HAS to be the top one!!) then we can pick any of the values in the Work Item section on the right hand side which are values that are stored in the activity’s parent SR, so for instance description highlighted below is the SR description of the parent SR that contains the child manual activity.

image

If you pick the ID on the right rather than the description, you’ll end up with something like this shown in the notification template (WHICH DOES NOT WORK, SO PLEASE READ ON AFTER Smile ).

CONTAINS ACTIVITY
$Context/Path[Relationship='CustomSystem_WorkItem_Activity_Library!System.WorkItemContainsActivity' TypeConstraint='CustomSystem_WorkItem_Library!System.WorkItem']/Property[Type='CustomSystem_WorkItem_Library!System.WorkItem']/Id$

If you leave it like that, guess how it comes out in the email.  It’s the big gaping space you see here under the second section where it says CONTAINS ACTIVITY:

image

The end result we want is the one shown below that which does show the Parent SR ID:

image

So how do we do that?  The secret is in a seedrole.  All you need to do is add this before the words TypeConstraint:

SeedRole='Target'

such that the old one which is this:

$Context/Path[Relationship='CustomSystem_WorkItem_Activity_Library!System.WorkItemContainsActivity' TypeConstraint='CustomSystem_WorkItem_Library!System.WorkItem']/Property[Type='CustomSystem_WorkItem_Library!System.WorkItem']/Id$

becomes this:

$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$

This is how it looks in the template:

image

And then once you have that you can substitute ID for any of the values you see available under work item.

2nd HEALTH WARNING: The internal name (which is what you need to put in the template) may not be what you expect based on the display name.  See below:

WORK ITEM:

Display Name Internal Name
Actual Cost ActualCost
Actual Downtime End Date ActualDowntimeEndDate
Actual Downtime Start Date ActualDowntimeStartDate
Actual End Date ActualEndDate
Actual Start Date ActualStartDate
Actual Work Hours ActualWork
Alternate contact method ContactMethod
Created Date CreatedDate
Description Description
First Assigned Date FirstAssignedDate
First response date FirstResponseDate
ID Id
Is Downtime IsDowntime
Is parent IsParent
Planned Cost PlannedCost
Planned Work Hours PlannedWork
Required By RequiredBy
Scheduled Downtime End Date ScheduledDowntimeEndDate
Scheduled Downtime Start Date ScheduledDowntimeStartDate
Scheduled end date ScheduledEndDate
Scheduled Start date ScheduledStartDate
Title Title
User Input UserInput

OK, great so far that we can add all these.

Now,  what if I need something SR specific like area, Urgency, Priority, Support Group, Source, Implementation results, Implementation notes etc.  Here’s that full list of possibilities:

image

Now we give ourselves a little more work to do Smile 

What we need to add is the Service Request class Internal name, the property internal name (not necessarily what you see in the table directly above), and the MP Alias referencing the MP  containing the class definition.   Here’s one way you can figure that out…

Create a notification template based on the class you’re trying to get properties for (like Service request) and then add one of the class specific properties using the insert button.  You should end up with something like this:

image

This gives me the 3 pieces of information that I need – the MP alias, the class name, and the property name:

$Context/Property[Type='CustomSystem_WorkItem_ServiceRequest_Library!System.WorkItem.ServiceRequest']/Area$

NOTE: Anything preceding a ‘!’ is an MP alias that should be found in the references section at the top of the MP where the alias is used.

So now going back to our manual activity notification template, we will start with the string we used to successfully get the Parent SR 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$

What we need to do is substitute the MP Alias, the class name and the property name.

$Context/Path[Relationship='CustomSystem_WorkItem_Activity_Library!System.WorkItemContainsActivity' SeedRole='Target' TypeConstraint=’MPAlias!ClassInternalName']/Property[Type=’MPAlias!ClassInternalName]/PropertyInternalName$

so the result is:

$Context/Path[Relationship='CustomSystem_WorkItem_Activity_Library!System.WorkItemContainsActivity' SeedRole='Target' TypeConstraint='CustomSystem_WorkItem_ServiceRequest_Library!System.WorkItem.ServiceRequest’]/Property[Type='CustomSystem_WorkItem_ServiceRequest_Library!System.WorkItem.ServiceRequest']/Area$

NOTE: You will also need to ensure the MP alias is included in the ‘references’ section of the MP that you’re creating the notification template in.  One easy way to do this is create a template based on the class in the same MP that you’re crating your manual activity notification templates (even just temporarily and delete the template when you’re done as the reference will persist).   In my case because I’m using the CustomSystem_workItem_serviceRequest_Library! MP Alias, I need to ensure the corresponding reference is in my MP where I’m storing my notification templates:

image

<Reference Alias="CustomSystem_WorkItem_ServiceRequest_Library">
       <ID>System.WorkItem.ServiceRequest.Library</ID>
       <Version>7.5.2905.0</Version>
       <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
     </Reference>

Now you can use the same string, but substitute the property internal name for other ones.  Here’s that handy-dandy list of display names and ID names so you can substitute as needed:

SERVICE REQUEST

DISPLAY NAME INTERNAL NAME
Area Area
Closed Date ClosedDate
Completed Date CompletedDate
Implementation Results ImplementationResults
Notes Notes
Priority Priority
Source Source
Status Status
Support Group SupportGroup
Template ID TemplateId
Urgency Urgency

So that’s everything you need right?  Well there’s one more part of the puzzle.  What if we extend our class and want to include extended properties from the parent SR in our manual activity notification.  Well the good news there is that it’s exactly the same as what we just did to get the SR-specific properties in, but instead we use the internal name for the extended version of our SR when we extended it in the authoring tool, together with an MP alias referencing the MP that we performed this extension in.

So for example…

Here is how an extended SR looks in the authoring tool with that all important internal name shown (please click on the image to see it better):

image

So in that case, our class internal name is ClassExtension_65552f71_c29d_4438_827c_9db6015c10b0

The MP this is stored in is the CustomProps MP.   Now we know this, we can create a template based on our extended class (in this case it will just be the OOB Service Request class), populate one of our custom properties with a value in the template, and then when I export the MP to XML (from Administration>Management Packs) I’ll get my reference:

<Reference Alias="CustomProps">
        <ID>CustomProps</ID>
        <Version>1.0.0.4</Version>
        <PublicKeyToken>b7e405a08a89a054</PublicKeyToken>
      </Reference>

Now if I don’t want that template any more, I can just go ahead and delete the template, and my reference will persist.

So now we have our MP Alias and our Class Internal Name.

MP Alias – CustomProps

Class Internal Name -  ClassExtension_65552f71_c29d_4438_827c_9db6015c10b0

The one last thing we need is out internal property Name which you can either find in the xml where your class is defined, or the authoring tool similarly to how we got the class name,

So in my case the end result is like this:

$Context/Path[Relationship='CustomSystem_WorkItem_Activity_Library!System.WorkItemContainsActivity' SeedRole='Target' TypeConstraint='CustomProps!ClassExtension_65552f71_c29d_4438_827c_9db6015c10b0']/Property[Type='CustomProps!ClassExtension_65552f71_c29d_4438_827c_9db6015c10b0']/ExtendedString1$

Using this approach you can include items from a parent SR (whether it be the OOB one, an extended one or an inherited one)

For completeness, I have included tables below for Incident and Change request Work Items (together with the SR and work item ones we saw earlier) as you might like to include these values in manual / review activity subscriptions where one of those is a parent item.

CHANGE REQUESTS:

DISPLAY NAME INTERNAL NAME
Area Area
Back out Plan BackoutPlan
Category Category
Impact Impact
Implementation Plan ImplementationPlan
Implementation Results ImplementationResults
Notes Notes
Post Implementation review PostImplementationReview
Priority Priority
Reason Reason
Required By Date RequiredByDate
Risk Risk
Risk Assessment Plan RiskAssessmentPlan
Status Status
Template ID TemplateId
Test Plan TestPlan

INCIDENTS:

DISPLAY NAME INTERNAL NAME
Classification Category Classification
Escalated Escalated
Has created knowledge article HasCreatedKnowledgeArticle
Last modified source LastModifiedSource
Needs knowledge article NeedsKnowledgeArticle
Resolution category ResolutionCategory
Resolution description ResolutionDescription
Resolve by TargetResolutionTime
Source Source
Status Status
Support group TierQueue

(and repeated from above):

SERVICE REQUEST

DISPLAY NAME INTERNAL NAME
Area Area
Closed Date ClosedDate
Completed Date CompletedDate
Implementation Results ImplementationResults
Notes Notes
Priority Priority
Source Source
Status Status
Support Group SupportGroup
Template ID TemplateId
Urgency Urgency

WORK ITEM:

Display Name Internal Name
Actual Cost ActualCost
Actual Downtime End Date ActualDowntimeEndDate
Actual Downtime Start Date ActualDowntimeStartDate
Actual End Date ActualEndDate
Actual Start Date ActualStartDate
Actual Work Hours ActualWork
Alternate contact method ContactMethod
Created Date CreatedDate
Description Description
First Assigned Date FirstAssignedDate
First response date FirstResponseDate
ID Id
Is Downtime IsDowntime
Is parent IsParent
Planned Cost PlannedCost
Planned Work Hours PlannedWork
Required By RequiredBy
Scheduled Downtime End Date ScheduledDowntimeEndDate
Scheduled Downtime Start Date ScheduledDowntimeStartDate
Scheduled end date ScheduledEndDate
Scheduled Start date ScheduledStartDate
Title Title
User Input UserInput

 

Happy Subscribing!  Cheers, Antoni