Inside VSTS

What Can You Use TFS For?

You can repurpose it as a help desk software, for one -- but it takes a little know-how. Jeff walks through the steps.

• By Jeff Levinson
• 07/29/2008

But lately, many companies have been looking at alternate uses for Team Foundation System, and guess which one shows up at the top of the list: a help desk replacement.

First, it's important to note the differences between help desk software and bug tracking software. This will help you understand what roles TFS can fulfill, as well as what roles it can't fulfill and why.

Help desk software is a bug reporting tool, bug tracking tool, customer relationship management tool -- that is, it provides updates, keeps histories, and manages contacts and status -- and knowledge base. It's also used across a wide range of scenarios: infrastructure tickets, password resets, software bugs, general help, etc.

A bug tracking tool, on the other hand, handles the technical needs of fixing a bug. It's a bug reporting tool and a bug tracking tool, and it provides detailed views into the changes made, who made them, when they made them and why. It also tracks the status of tests performed on the bug fix, the builds that the fix is in and the release that contains the bug fix.

In short, a help desk tool is a customer-facing tool while a bug tracking tool is a technical (development team)-facing tool. Knowing this, what can one piece of software do that the other can't?

Help desk tools don't track the status of a technical fix (you'd almost never report to a customer that the bug was fixed in Build 135 but then failed testing and had to be fixed again). They don't usually understand the internal workings of a development team and know that bugs get triaged, then fixed, then tested, then built and finally released. Bug tracking tools don't typically have a CRM portion; in other words, they don't provide notification to end users and they don't maintain a knowledge base. And there's hardly ever a relationship between help desk software and bug tracking software in terms of one system updating the other and vice versa.

Whew. OK, now that you know what each piece of software is used for, how does TFS come into play?

TFS handles the role of tracking bug fixes extremely well. It understands your development process and has definitive flow. In one sense, it does have a knowledge base because you can search for other bugs of a given type or see how many bugs have been noted against a given module in an application. Additionally, it can provide notifications, especially with the release of the July TFS Power Tools (which you can read more about here on Brian Harry's blog).

But because TFS was built for a specific purpose (software development), it doesn't do some things well at all. For one, it doesn't maintain customer contact information. A bug work item contains the person who created it and the person to whom it's assigned, but it doesn't contain information on the person who reported it. Also missing are the nice screens that most help desk software have with lists of prior incidents the customer called about, the average resolution time of issues, a listing of all prior and related incidents, as well as "help scripts." So it would seem that out-of-the-box, it doesn't quite fit as a piece of help desk software.

Using the customization features of TFS, you can recreate quite a bit of the help desk software -- but you have to understand that you're using it for a purpose other than what it was created for and it will require a bit of work.

You can customize work items to allow for the name of the person who called in and filed the bug. Because TFS integrates with Active Directory, you can create a custom control which will look up the person's contact information (or you have to enter it again every time, which tends to make customers upset). You can also fix the notification tool such that it could send updates to the customer who filed the bug.

But does it make sense to do that?

In a small company, using separate help desk software is usually not necessary and TFS can support the role well enough. However, in a larger company, I would advise against it.

A better solution is to use the available TFS API to plug TFS into a larger help desk software system to allow for an easy flow of information from technical systems and back again to provide a seamless experience.

The one thing to consider before you repurpose TFS (even for something other than a help desk system) is to consider the cost both in customization and maintenance. Is it better to buy a specialized piece of software? That will depend on your specific situation, but it does bear some thought as TFS is already a great bug tracking tool.