Template IDs, the "safer" way to build criterias

Many criteria is based on work item titles in conjunction with other properties. Often the title is the defining property for the criteria, ex. Title equals "Grant employee access to system" and Status equals "In progress". This title is not exactly unique and could easily be repeated elsewhere.
Maybe the title needs to be changed in the template, but tens or hundres of work items based on the current form of the template is still dependant on a criteria mathing their exact title, and you would need to change the title for all of these (using PS!).

The solution: Extend your favorite work items with a single field: "Template ID", or simply use existing extension properties. In this field you enter a unique ID and use this as criteria for your workflow/subscription/view/whatever. It can even be used in a PS Filter

You can use the PS snippet below to generate a GUID (it is placed in the clipboard by piping to clip)

[guid]::newGuid().tostring().replace("-","") | clip

edit:
All templates have an ID which is definde in the MP containing the template. Look for <ObjectTemplate ID="....". This ID is carried into the instance of Runbook Automation Activities to the property TemplateId - check for yourself using powershell or simply in the history tab. Service Requests also have a property TemplateId but the template ID (from xml) is not carried into the instance of the SR template unless it is a default service request, one would have to manually edit the xml to do this.

Including extension properties in the description field

User input is often mapped to extension properties of Manual/Review activities. The input can be made easier to comprehend by adding labels to each:

As a service to activity implementors these properties can be included in the description field as part of a complete text (with some Orchestrator magic!). A simple example is a password reset where the line manager must approve or decline a request for a password reset. The description field could read something like

User has requested a password reset. See extension tab for further details.

The extension tab could then include a username and a reason for the request. I will now show how the description could be changed automatically to:

CB.IT has requested a password reset with the following reason: "I changed my password yesterday and now I cannot remember what it is".

The title could also be changed to:

Approve password reset - CB.IT

One approach to implementing this feature is to use Markup Language and Orchestrator. For this particular example one would first change the "password reset" template where the description field should look like this:

<CB_CstmTxt1> has requested a password reset with the following reason: <CB_CstmTxt2>.

This is a simple way of telling Orchestrator that we would like to substitute the tag <CB_CstmTxt1> with the value in the extension property named CB_CstmTxt1 (containing the username of the requesting user). CB_CstmTxt2 then contains the reason for the request. To change the title we would put

Approve password reset - <CB_CstmTxt1>

Next up is creating a monitoring activity in Orchestrator that looks for new Review Activities, and then updates them using Powershell:

The script:

Import-Module SMLets

$ID = 'RA29'
$RA = Get-SCSMObject -Class (Get-SCSMClass -Name System.workitem.Activity.ReviewActivity.extension) -Filter "DisplayName -like '$ID%'"

$PropertyNames = $RA.GetProperties() | select -ExpandProperty Name

$Title = $RA.Title
$Description = $RA.Description

foreach($P in $PropertyNames)
{
    #$P
    $Value = $null
    try {
        $Value = $RA | Select -ExpandProperty "$P"
        if($Title.Contains("<$P>"))
        {
            $Title = $Title.Replace("<$P>", "$Value")
        }
        if($Description.Contains("<$P>"))
        {
            $Description = $Description.Replace("<$P>", "$Value")
        }
    }
    catch [System.Exception] {
        # value is null
    }
}

# uncomment below to echo title and description
#"$Title, $Description"

$PropertyHash = @{"Title" = $Title; "Description" = $Description}
$RA | Set-SCSMObject -PropertyHashtable $PropertyHash

This will be modified slightly to work in a runbook. Edit the $ID variable and try it out in your own environment. For the runbook edit to filter on "ID" and compare to the GUID provided by the monitor activity.