It's all about the answers!

Ask a question

Workflow status shows number instead of status when I changed workflow for work item type

Matthias Heindl (1111) | asked Nov 14 '12, 9:04 a.m.
I have a work item type "requirement" which was linked to the "defect workflow".
Now, I copied the "defect workflow" and assigned the new workflow (which is exactly the same as the original defect workflow) to the requirement work item type.

When I do this, the status and resolution fields of existing items are showing numbers of "not initialized" instead of the correct values.

How can I make the new workflow work?

The next step would then be to adapt the new workflow, i.e. change status and actions.
Thank you in advance!

Kevin Ramer commented Nov 14 '12, 1:28 p.m.

In the Project Configuration you can look at the work item configuration and there are links relating to the attributes and work flow labeled something like "check xxxx usages in repository"

Try clicking on the one for the work flow.  It may offer some help (I think you can show the incorrect usage or change the work flow binding)

Matthias Heindl commented Nov 15 '12, 2:36 a.m.

Hi, thank you for your answer.
When I use this link I get a message that I have 14 work items having a state which is not existing in the workflow.

But this is strange, as I copied the old workflow. So it should have the same status as before!?

Albert Yao commented Jun 25 '13, 8:38 a.m.

I also think this is strange and the problem should be a bug. I just copied the workflow, why the status lost?

2 answers

permanent link
Stuart Cornell (1125) | answered May 23 '13, 4:28 a.m.
 I am seeing the exact same issue and it makes it effectively not possible to change the workflow for existing task types. 
This is necessary because in my project task and defect both use the default workflow. If I want them to have different workflows then I need to map one of them to a new workflow but this will mess-up existing work items.
Surely this is a bug which should be fixed.
I saw a thread here which suggested switching items to another workflow and back again to fix the surrogate workflow item, but that doesn't work either as it seems to lose the task state in the first switch and I don't want to break my existing task items.
Any other suggestions?

permanent link
Ralph Schoon (60.7k33643) | answered May 23 '13, 8:13 a.m.
edited May 23 '13, 8:14 a.m.
A work around could be to

  • export the data (ID and state) to CSV prior to switching to the new workflow
  • Switch to the new workflow
  • import the ID and state using the CSV import with update

If you think this is a bug, I would suggest to consider creating a PMR or you can also create a work item here:

Stuart Cornell commented May 23 '13, 9:02 a.m.

Thanks for the suggestion Ralph. I have managed to workaround it by cloning and changing the defect type and workflow only. I can do this as I have no defects yet in my project. 

Your answer

Register or to post your answer.