It's all about the answers!

Ask a question

Using Resolution field for non-closing State


Michael Walker (99215201157) | asked Apr 27 '11, 2:22 a.m.
Hi,

I've received several requests for a Blocked state from my team with different examples of situations where it's needed. I was thinking of adding a Blocked state to the Workflow and using the Resolution field to list the reasons why it would be Blocked that the user could choose from.

Is this an ok way to use the Resolution field considering it isn't a closing state or should I use a new field to capture this info?

Comments
Nate Decker commented Mar 04 '16, 12:43 p.m.

This is an old question and probably no longer of interest to you. That being said, I thought I would weigh in on this since this forum is not only for answering questions of the original poster but also as a reference to others.

If you use a Resolution value for this purpose, then you have to either:

1) Allow the resolution to be displayed through additional states so that you can display those values. You might also want to be able to change them.

2) Alternatively, if the resolution field is only available on the work items while they are in the "Blocked" state, then that has to be the only time anyone cares to see/use that value.

Basically, the problem with the resolution versus other attributes is that it is only visible and modifiable during certain states. It's possible you may want to see or use that resolution value in states beyond the 'Blocked' state.

Incidentally, we also implemented a 'Blocked' state in our own implementation, but didn't provide resolutions. We assume the end-user will document the reason for the blockage in the description or some other text field of the work item.

2 answers



permanent link
Michael Walker (99215201157) | answered May 02 '11, 3:17 a.m.
Normally, one uses the "blocked by" relationship to indicate that you
are blocked by something. The advantage of the relationship is that it
tells you what you are blocked by, and you can automatically tell when
you are unblocked when the work item you depend on is transitioned to
"complete". But you certainly could add a Blocked state to your state
values as well.

Cheers,
Geoff

On 4/27/2011 2:23 AM, miwalker wrote:
Hi,

I've received several requests for a Blocked state from my team with
different examples of situations where it's needed. I was thinking
of adding a Blocked state to the Workflow and using the Resolution
field to list the reasons why it would be Blocked that the user could
choose from.

Is this an ok way to use the Resolution field considering it isn't a
closing state or should I use a new field to capture this info?


Thanks Geoff,

We do use the Blocked By relationship to some degree, but there are instances where items are blocked on something that isn't represented by a work item and I don't think I can convince them to create a new work item each time this occurs.

permanent link
Geoffrey Clemm (30.1k33035) | answered Apr 28 '11, 9:51 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Normally, one uses the "blocked by" relationship to indicate that you
are blocked by something. The advantage of the relationship is that it
tells you what you are blocked by, and you can automatically tell when
you are unblocked when the work item you depend on is transitioned to
"complete". But you certainly could add a Blocked state to your state
values as well.

Cheers,
Geoff

On 4/27/2011 2:23 AM, miwalker wrote:
Hi,

I've received several requests for a Blocked state from my team with
different examples of situations where it's needed. I was thinking
of adding a Blocked state to the Workflow and using the Resolution
field to list the reasons why it would be Blocked that the user could
choose from.

Is this an ok way to use the Resolution field considering it isn't a
closing state or should I use a new field to capture this info?

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.