How to mark an issue as waiting on client

[Dan Williams]

To clarify, I'm NOT using JIRA Service Desk, I'm using JIRA Core.

We're using JIRA to track issues in a design/software company.

Often issues are waiting on some client action; examples are:

• waiting for a spec
• waiting for a quote to be approved
• waiting for a client to provide content
• waiting for a demo to be signed off

I've tried to implement this by using custom workflows, but there are some downsides to this:

• We have to create a lot of statuses (is this bad? It makes workflow diagrams complex, and means there's a lot of transitions to different 'waiting on client' statuses)
• Issues in some 'waiting on client' state stay in our "my issues" queue. I can filter them out with a custom filter, but I have to manually select all statuses I want to see; I'm concerned that I might start missing issues if I then alter the workflows again
• I have to select a status type (Todo/in progress/done) for these statuses; but 'todo' and 'in progress' seem to suggest that the issue is in our ball court to deal with, and 'done' seems like it should only be used for resolved issues. There doesn't seem to be an appropriate status type, which suggests to me perhaps I'm doing it wrong? I feel there should be some way to group all these 'waiting on client' type statuses.
• I want to add an automation task to remind us to nag customers who aren't responding (I think I can use ScriptRunner for this?) but again, I suspect I'd need to manually select all the 'waiting on client' statuses, which feels wrong.

Am I doing this the right way, or is there a better way? This seems like a very common issue JIRA users would have, but I can't see any obvious solutions.

[Dave Theodore [Coyote Creek Consulting]]

As with everything in Jira, there is more than one way to tackle a problem.  When we do this type of work for clients, we favor the simple approach. This makes it easier t manage, for someone with less expertise that we have. It also generally costs less and will have less of a negative impact on performance. You could go crazy with a bunch of Apps, customizations, etc and build exactly what you are describing. Or, you can get close with the use of built-in functionality and maybe an App or two.  I recommend the latter approach.

In your example of "waiting for..." all of those have in common that you are waiting for some action that is out of your control.  I suggest creating a single Workflow Status to represent this, say "Need Info," and adding a Transition Screen and Custom Field to indicate the reason you're waiting, say "Reason for Waiting." Just add your four reasons to the Custom Field and possibly install a 3rd party App that adds a "Field required" validator to ensure that people select a value from the field. 

You will need to look at the what JQL is used to feed your "My Issues" queue. If you are referring to the "Assigned to me" Dashboard gadget, the issues are ones that have you listed as the Assignee and have no Resolution set on them.  By making the workflow change I am suggesting, it will not cause the issues to stop being displayed there.  You could do some Post-function magic to copy over the Assignee user in to another field, say "Last Assignee," then clear the Assignee (requires your Jira instance to allow unassigned issues,) when things go in to the Need Info workflow status, then copy it back from the Last Assignee field in to the Assignee field when it exits the Need Info status.

Jira has a feature called Filter Subscriptions (scroll to the bottom and look for "Subscribe to search results) that will send out an email digest of issues that appear in the Filter results.  If no issues appear, no email will be sent.  If you can live with that formatting, there is no need for a 3rd party app to perform this function. You could also create a custom Dashboard and have a Filter Results gadget that performs this action if you prefer the "pull" model.

Hopefully that helps point you in the right direction.

[Dan Williams]

Thanks, that gives me some very helpful ideas; I'm still fairly new to JIRA so I've not looked into the post-function stuff, that sounds very helpful, as does filter subscriptions.

I'll leave this open for a little while because – as you say – there's more than one way to tackle the problem, and I'd like to give a chance for anyone else to recommend their approach.