best practices on Resolution field

[Sabine Van Regenmortel]

When I read this article on best practices when using the Resolution field, all criteria are met in our workflows.
At the moment of resolving the issue, we do split the resolution into 2 transitions Fix Issue or Abort issue, which respectively sets Resolution to Fix or Abort.  This way we can distinguish easily the real problems that were fixed versus the user errors, no business cases etc.

Now among our users is a project lead who wants to get rid of the Resolution field. I tried to convince him with the arguments stated in the article, but he is not convinced.

How do I convince him, and are there among you use cases where the resolution has more than one option?

[Pete Singleton]

Personally I think the resolution field is more important than the workflow status.

If the resolution is not set, then Jira will consider the issue to be unresolved, i.e. still open.  This will affect reports, dashboard gadgets, release progress etc.

Now, you could have the resolution set automatically, via workflow transition.  This makes the user experience simpler, as a user can just move an issue to the workflow state of "Done" and have the resolution automatically set to "Done" as well.  However, if you choose this route then I would always advise that you have more than one available end state in your workflow, i.e. have something like Cancelled or Rejected as workflow states as well as Done.  For obvious reasons, not all issues end up Done.

It's a common confusion among users, the difference between Status and Resolution.  I would suggest having it set automatically via workflow, that way you can still use the field for reporting etc, but it's effectively invisible to the end users.

[Sabine Van Regenmortel]

Thank you for your reply.

I totally agree and I have set my workflows for more than 10 years now with the resolution set or cleared every time a transition is executed.
Still it is questioned again and again and every now and then there are users who want to reinvent the wheel.  Very exhausting.

Maybe it is not obvious enough to an end-user because they cannot see the graphical workflow.
To us administrators, the whole flow with transitions and field settings is always in the back of our minds when pressing a transition button.

In your case of resolution Done (actually just a toggle to indicate whether it is resolved or unresolved), invisibility to the end user is an advantage.
But in my case with resolution Fix or Abort, I think they are more confused that it 's invisibly set in the workflow.

[Pete Singleton]

So what does the workflow look like?  What status are they transitioning to when they close an issue?  If you had a workflow that went to Fix or Abort, with the resolution set automatically on each, how could they find this confusing?

[Sabine Van Regenmortel]

Workflow is Created - In Progress - Resolved (Fix or Abort) - Closed (Fix or Abort).
They transition to status Closed with transition Approve Resolution.
They transition to status In Progress with transition Reject Resolution.

With a lot of communication we have now come to an agreement...

Thanks for replying (didn't get a notification, sorry for the delay..)

[Ema Walker]

 What reputation are they transitioning to once they close an trouble? If you had a workflow that went to Fix machine or Abort, with the resolution set mechanically on every, how may want to they locate this puzzling?

[Alicejohn]

yes if you had a workflow that went to Fix machine or Abort, with the resolution set mechanically on every

[The Reality Facts]

if you had a process that either proceeded to the Fix machine app step or the Abort step, with the resolution being set automatically on every step, then the answer is yes.