Build association with work Items in vNext

When switching from XAML to vNext, I realized the newer build model doesn’t update Global List. Old XAML builds enabled a work flow where work items were created on build failure and then updated those work items, associated with check-ins on successful builds. I couldn’t find a similar feature happening out of the box on the vNext model. However I was able to write a sample script to work around and get similar features.  In this blog, I am going to explain the same in detail.

Found in build field:

  1. Open the build definition and go to Options tab.
  2. Enable “Create work item on failure” and set the type to be Bug (or any work item of your choice)
  3. Add a field (by clicking on Add field button) and set the following

             Field - Microsoft.VSTS.Build.FoundIn and Value - $ (Build.BuildNumber)


This would create a new work item on build failure with the failing build set.



Integrated in build work flow:


Using XAML templates, you might have noticed the “Integrated in Build” field is auto updated by the build process which picks up the bug resolution through a changeset at check-in time, however it’s not the case in Vnext and switching to Vnext you might want this updated, hence this blog post.


In order to get the “Integrated in Build” updated, the following steps will help.


Using PowerShell, we will find the work item associated with the build in progress.

On success of the build, using REST API we will update the “Integrated in build” field with the build number.


Step 1:

Add two variables to the build definition.
RestUserName -> Service account (or any other account that can access TFS)

RestPassword -> Password for the account (encrypted so that it’s secure)


Step 2: Create a PowerShell file and copy the content below.








$basicAuth = ("{0}:{1}" -f $RestUserName, $RestPassword)

$basicAuth = [System.Text.Encoding]::UTF8.GetBytes($basicAuth)

$basicAuth = [System.Convert]::ToBase64String($basicAuth)

$headers = @{Authorization=("Basic {0}" -f $basicAuth)}



[String] $BuildUrl = “$env:BUILD_BUILDURI“

[String] $project = “$env:SYSTEM_TEAMPROJECT“

[String] $BuildId = "$env:BUILD_BUILDID"

[String] $BuildNumber = "$env:BUILD_BUILDNUMBER"






$WorkItemAssociatedURL = $collectionURL + $project + "/_apis/build/builds/" + $BuildId + "/workitems?api-version=2.0"

$ResponseJSON = Invoke-RestMethod -Uri $WorkItemAssociatedURL -ContentType "application/json" -headers $headers -Method GET


$CountWorkitems = $ResponseJSON.count

$WorkitemUrlArray = $ResponseJSON.value


for($i = 0; $i -lt $CountWorkitems ; $i++)


$body =



"op": "add",

"path": "/fields/Microsoft.VSTS.Build.IntegrationBuild",

"value":' + $BuildNumber +'




$WorkitemUpdateURL = $WorkitemUrlArray[$i].url + "?api-version=1.0"


Invoke-RestMethod -Uri $WorkitemUpdateURL -Body $body -ContentType "application/json-patch+json" -headers $headers -Method Patch






Write-Host "No work item associated with this build. Kindly check the changesets"



Step 3: Add a PowerShell task at the very end of the build definition and then select the PowerShell.

In the Arguments pass the UserName and Password -> $(RestUserName) $(RestPassword) 4

On build, we will see this behavior

5 6This works for both VSTS and OnPrem TFS. However setting authentication for REST API differs on both. Getting started with REST can be found here.

Content : Venkata Narasimhan
Reviewer: Vimal Thiagaraj