Day 38: Storing the Service Manager Work Item Id In A Custom Field In TFS

Welcome to Day 38 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 order to facilitate true bi-directional communication between Team Foundation Server (TFS) and System Center Service Manager (SCSM), I need to have fields in both systems to store the work item ID from the other system.  I’ve already shown you how to do this for SCSM in “Day 33–Storing the TFS Work Item ID Back In Service Manager”. In this post, I’ll show you how to add a new field to the TFS Task Work Item Type, and how to update that field from my powershell script.

Adding A Custom Field To a TFS Work Item Type

TFS work item types, such as the Task, are simply stored as XML files.  The easiest way to edit them is to use the Process Editor that comes with the Microsoft Visual Studio Team Foundation Server 2013 Power Tools Update 2.  Make sure you have installed the Power Tools before continuing.

Open Visual Studio and select TOOLS | Process Editor | Work Item Types | Open WIT from Server.


This opens the Connect to Team Project Collection dialog box. Select the appropriate Team Foundation Server and Team Project Collection, then click Connect.


I’m then prompted to select the work item type that I want to edit. By opening the work item type directly from the server in this fashion, any changes I make will be saved back to the server immediately. I select the Task work item type and click OK.


The TFS Work Item Type Process Template Editor consists of three tabs: Fields, Layout, and Workflow.  For the purposes of this post, I only care about two of the tabs: Fields and Layout.  The Fields lists all the fields for the Task work item type.


To create a new field, click the New button.  Fill out the Field Definition window as shown below.  This creates a new string field called SCSM Work Item Id, where I can store my work item id from Service Manager. Fields in TFS can have rules applied to them, such as making the fields Read Only. For now, I won’t worry about applying any rules, and click OK.


In the image below, I can see that my new field appears on the Fields tab.


Now I need to modify the layout of the Task work item form, so that my new field will appear on the form. Click the Layout tab to see the defined layout for the Task work item form.  I want to add my field to the second column that appears on the form, so I right-click on the columns under that group, and select New Control from the context menu.


This creates a new control. I set the Field Name of the control to be my new field, selecting it from a drop down list of all the fields on the task. And I specify the label for my control.


I can click the Preview Form button to see what the new form will look like.  The new field, SCSM Work Item Id, appears underneath the Area field, right where I want it.


To save my changes back into TFS, I select File | Save from the main menu.  Since I opened the work item directly from the server, when I save my changes, it applies them immediately to the team project.  If I open an existing or new Task work item in TFS, I can now see the new field.

Modify PowerShell Script To Set The Custom Field

My blog post, “Day 33–Storing the TFS Work Item ID Back In Service Manager”, contains the latest PowerShell script and process for updating the TFS Task work item, and storing the TFS Work Item Id back in SCSM.  To make use of the new field I added to the Task, I need to modify the script slightly.

Here is the new script to use:


All I have done is add the following line:

To set any field on the work item, you can include the field name in brackets, as shown above.  If you take the above script and put it into the custom workflow created on Day 33, you will now be setting values to your custom fields in both TFS and SCSM.  At this point, I have created everything I need to establish two-way communication between TFS and SCSM, so that when a work item is updated in one system, it gets updated in the other system.

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.