Day 33–Storing the TFS Work Item ID Back In Service Manager

Welcome to Day 33 of the “100 Days of DevOps with PowerShell”! For background on our goals in this series, see Announcing the “100 Days of Devops with PowerShell” Series here at SCC.

In my previous post, “Day 28 – Let’s Integrate System Center Service Manager and Team Foundation Server”,  I showed how to create a new Task work item in TFS when a new Incident is created in Service Manager.  The next step toward bi-directional communication between the two systems is to store the TFS Task ID in the Service Manager Incident. In this post, I’m going to show how to extend the Service Manager Incident Class with a new field, and how to modify the workflow created in the previous post to update the new field.

Extend The Incident Class With A New Field — TFSWorkItemId

I’m going to add a new field called “TFSWorkItemId” to my Incident class.  I start off by opening the Service Manager Authoring Tool, and opening the TFS.Integrations.xml management pack that I created in my last post.  In the Class Browser tab, select All Management Packs from the drop down list at the top. Enter Incident in the Search window, to filter the list of classes displayed.  Find the Incident class, right-click on it twice (don’t ask, its an authoring tool issue”, and select View from the context menu.


In the Management Pack Explorer tab, right click on the Incident class, and select Extend Class from the context menu.


You will be prompted to save your new extended class into the TFS.Integrations management pack.  Click Ok.


On the Extension of Incident tab, rename the incident to be TFS Class Extension of Incident. Click the Create Property button to create a new property on the class. Enter TFSWorkItemID on the Create Property window and click the Create button.


I now have a new property on my Incident class named TFSWorkItemId, where I can store the work item ID returned from Team Foundation Server.

Modify Workflow To Set This New Property

I need to modify the workflow I created in the last post to set the new property on the Incident, once the work item is created in TFS. Double-click the CreateTFSTaskFromNewSoftwareProblemsIncident Workflow to open it.


Select the CreateTFSTaskFromNewIncident activity. In the Details tab, next to the Script Body property, click the ellipse to open the script. Update the script to be this:

Let’s look at the changes. At the top of the script we added import-module SMLets. This imports the SMLets, allowing me to use them later in the script. The rest of the changes happen at the bottom of the script:

Here, I am getting the work item ID for the TFS work item. Next, I get a reference to the Service Manager Incident Class, and then I retrieve the Incident by calling Get-SCSMObject, and applying a filter off the Id property of the Incident. I create a hash table containing the fields I want to update (in this case, one field, my new property). And finally, I call Set-SCSMObject to update the incident in Service Manager.

With my script updated, I save all my changes in the Authoring tool, then copy the CreateTFSTaskFromNewSoftwareProblems.dll to the Service Manager Management Server, as I did in the last post.

I open the Service Manager console and import the new version of TFS.Integrations.xml I just created.  After importing the management pack, I need to close and reopen my console. Otherwise, I won’t be able to see any changes made to my new property.

To test my changes, I create a new incident with a Classification Category of Software Problems and save it.  After a minute or so, I look in Team Foundation Server and see a new Task Work Item related to the Incident I just created.  If I open the Incident in Service Manager, and go the Extensions tab, I can see that the TFSWorkItemId field has been populated with the ID of the Task from Team Foundation Server.


I’m half-way toward my goal of bi-directional communication with Team Foundation Server.  In my next post, I’ll show how to extend the Task work item type in TFS to have a custom field to hold the Incident ID.  Once that is in place, I can then start building workflows that watch for changes in one system, and replicate those changes to the other.

Previous Installments

To see the previous installments in this series, visit “100 Days of DevOps with PowerShell”.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.