Integrating Zendesk and Visual Studio Team Services

Posted by Gary Skinner
  • Blogs
System Integration

At Netcel we strive to deliver results in line with our core values of Progressive, Agile, Collaborative Excellence. As such, we in the support team constantly look for ways to streamline and improve our systems and processes for the benefit of our clients. Early in 2016 we spotted a way to integrate two of our core systems - Zendesk and Visual Studio Team Services (VSTS), to create significant efficiencies.

Currently our clients register ongoing support tickets with us through the Zendesk ticket system, while for new projects, work items are usually packaged and processed via VSTS. For our quality assurance and development teams this means keeping track of two major workflows.

While Zendesk and VSTS platforms offer excellent functionality individually, the risk with managing them as standalone systems is duplication of client requirements and corresponding activity. This is a situation Netcel want to avoid, so to facilitate seamless working between our Support Services and Technical Development functions  we decided to implement a bespoke integration of the two platforms using standard service hooks available in VSTS and by means of a Zendesk app. Further details can be found at

With a bit of extra tailored configuration of the two platforms Netcel is now able to efficiently track the relationship between support tickets and developer tasks. The resulting benefits are that:

•    Testing acceptance criteria and requirements remain separate and focused
•    Information is both clear and relevant to the department
•    Clients can track requirements and ticket progress easily
•    Support team and developer can communicate more effectively
•    Tickets involving coding are processed more rapidly and efficiently within VSTS, supported by clearer acceptance criteria. This results in reduced client costs combined with a swifter, higher quality output
•    Potential issues in implementing client requirements are spotted early due to clear visibility within VSTS

A good example of this would be if a client logged a ticket on Zendesk requesting a banner area to be added to a page: “I would like to add a banner to the top this page: It should appear below the navigation in the main body and display across the page. I want to be able to set a different banner for each language branch. The property should be optional.”

After reviewing the request we would gather the necessary teams together to determine requirements. These would then be passed to the client to confirm or change. Once agreed, the requirements would be used to create a task in VSTS.

QA will use the task in VSTS to test for bugs or issues. There would be no duplication of effort or to’ing and fro’ing between the Zendesk ticket and the VSTS task. Communication between QA and the developer would take place within VSTS but would also be visible internally on Zendesk.

Once QA approve the work it would be deployed to UAT for the client to review using precisely the same requirements and acceptance criteria to ensure the same test steps are followed.  The result is a swift, seamless process with clear communication between Netcel teams and the client at all stages.

For anyone contemplating integrating VSTS with Zendesk here are a few lessons we learned along the way:

1.    You will need Zendesk admin rights
2.    Once an API token has been created to allow VSTS to communicate with Zendesk do not delete it. If you do you will need to update all VSTS clients projects with a new API token
3.    If you create a new Zendesk user (which will be used when a comment is made in TFS and pushed to Zendesk), do not delete the user
4.    Before you log in to the new Zendesk VSO app, you will need to configure your VSO account to use alternate credentials – ‘Alternate Authentication Credentials’
5.    You will need to configure VSO to allow TFS comments to be added to internal notes on Zendesk

For Netcel, going forward, we will also be using the new VSTS and Zendesk integration for tasks that were previously out of the scope of our Technical Development team and action them in Support. This will not only speed up delivery and increase capacity but will ensure client requirements are captured and not lost during the transition from a development project to a support project.

In the meantime we will continue to seek out ways to improve the service we offer our clients and the experience they encounter with us.