We are implementing TFS and there is a methodology describing the processes we have to follow during the development of new features. The initial work is done on top of several Word docs (Vision Document, Use Cases, Test Cases and so on). We would like to create some kind of workflow like :

1. The Requirements guy creates the Use Cases doc;

2. The Quality guy now has to review and approve the Use Cases.

2a. If approved, the Architect starts turning Use Cases into taks to the Developers;

2b. If not, Requirements guy receives the "Why Not Approved" doc and goes to 1;

3. Development guy picks one task and codes it;

... And etc.

Since TFS has a Source Code Control feature, we initially thought about storing the docs on TFS SCC, but I could not see how to implement the workflow control if the docs are on the SCC. Perhaps I'm not using TFS right It would be better do to the workflow on the team project portal TFS creates Is there any drawbacks on storing the docs on SharePoint instead of TFS SCC Have you guys any experience on a scenario like this

Thanks a lot,


Re: Team Foundation Server - General Document workflow on TFS?

Gregg Boer MSFT

I'm interested in what non-Microsoft people would say to your post. However, I will where we are thinking about internally on the TFS team. Right now, we've had a lot of questions around what is our document storage store Is it WSS or is it SCC

SCC offers branching, labeling, etc...

WSS offers easy accessibility outside Visual Studio, and also provides workflow.

One idea I've been toying around with is providing the ability to link a work item with a WSS stored document. The information between the two items would be mirrored, and changes to one would affect the other, especially states. You could, from the work item, have an easy launch point to edit the document, but could also do it from WSS as well.

Do you think a solution like this would work for you

Re: Team Foundation Server - General Document workflow on TFS?


Hi Gregg,

First, thanks for your reply. I believe by reading what you said that the original idea we came up, of storing the documents on WSS ad using its workflow features, is the way to go, correct

I really don't know if the link between the work item and the document on WSS would bring any aditional functionality. As you said, it would make easier to launch the document for edit, but I already have this launching point from inside the Team Explorer window.

Our point of view here is that the documents, as artifacts delivered during the project development, should be on TFS SCC. Mainly because of branching to control multiple project versions. If we had this link between a work item and a doc, and we branched the project, to what doc version would the work item be associated It seems that we would end up creating one team project to each project version, so the work items - and the workflow features - would be associated with a specific version of the documents.

Perhaps if we could "branch the project portal" as well Following this vision of having a workflow in progress to each project version, this seems to maps inside TFS what is happening on the "real world". Another possible vision is to have some kind of "workflow client", and expose the documents on TFS to this client, so we could create several workflows - one for each project branch, or for a given set of documents, or for any group of docs we want.

Or, as I said on my initial message, maybe I'm just trying to fit TFS were is not supposed to. I would very much appreciate your thoughts on how you would implement the scenario I described with the current features of TFS.

Thanks again,


Re: Team Foundation Server - General Document workflow on TFS?

Gregg Boer MSFT

The short answer is that TFS currently, whether you use SCC or WSS, doesn't provide a full solution. To me, a full solution includes:

  • Workflow
  • Web access
  • Traceability (link doc to work item)
  • Branching/Labeling
  • Querying

I will say that our direction is to use WSS to handle documents for TFS-based projects, and continue to enhance that integration to get a full solution. For now, to get the branching/labeling, you'd have to handle that manually with WSS, that is, copy the files to a new document library to create the "branch"

Having said that, I believe there is a strong case for SCC, especially if whoever is writing the requirements doesn't have an aversion to working VIsual Studio / TFS / Source Control. Many of our customers say their requirements anaylsts won't go near VS. :-)

I realize this is not a definite answer, but hopefully it does provide more information.

- Gregg

Re: Team Foundation Server - General Document workflow on TFS?


Hi Gregg,

Your answer corvers all the points I wanted. I can see now that the tool does not cover automatically all the functionality we wanted - not yet, I mean. But it helps a lot on automating the process we are implementing.

Good idea on the "branching mechanics" inside WSS Wink I'll use it.

Our requirement analysts are usually the solution architects, so they are used to working inside VS. But I can see the problem you said of using Team Explorer as the access point to the documents. I have seen my share of "technofobic" users....

Thanks a lot for the help,