Work flows for Jira Service Desk

[akempler-delugach]

I am working on applying one workflow (for a service request) to several different custom request types. These request types need different status names for each status. In the edit fields area, you can change the status labels that the customer sees, is there any way to change the status labels that the service desk worker will see for a certain request type, not at the workflow stage.

[Mike Rathwell · Accepted solution]

Hi @akempler-delugach ,

What you're embarking on is possible but not... simple... To my mind, this might actually make it a bit harder to have a common workflow that fits All The Things. That said, what you might try to do is expand your workflow to have the different statuses after the one you expose to the JSD customer. Some suggestions:

• Use the Jira Misc Workflow Extensions plugin which, to my mind, should be in every Jira Administrator's toolbox. With that you could automatically and conditionally transition to a given status after reaching the status exposed to the JSD customer
• Leave it manual; when it lands in the customer exposed status, the service desk agent transitions to the correct status for the particular Customer Request Type. You can set conditions in the workflow to only allow it to go to the status you want.
• After the cycle that a given customer request type is run through, have it transition to a status you want to expose to the customer.

All the above stated, the approach I took was to work out what all the different request types had in common and came up with a single workflow that addressed all of them natively. So far, the one I built has worked well for 3 rather disparate teams (tech help desk, office service requests, and security requests). The differentiator is what I did for each of their queues so they had visibility to the tickets they needed to see and separated them out by customer service request type. In that single workflow, I have a couple of "in work" statuses that aren't exposed to the customer to keep what is going on "in house" as it were and conditional to cycle to those only if needed.

[akempler-delugach]

Hi @Mike Rathwell , 

Thanks for the great suggestion! I assume you have made automations for these cases. This is definitely something that might work for me. 

[Mike Rathwell]

@akempler-delugach , you are exactly right... I have both automations driven from JSD and I've got a lot of stuff baked into the workflow (conditions, validators, and post functions, most of them driven by JMWE) that makes it do what I want it to do. In most cases, once I got the workflow "right", I only have to code for the "edge cases".

[Mike Rathwell]

Also... don't forget to "Accept Answer" on stuff that gets you going from any of us here :-P

[akempler-delugach]

Thanks @Mike Rathwell , quick question while I am working on this. Do you know if you can delete an issue through the normal automation tool in jira service desk?

[Mike Rathwell]

The short answer to taht @akempler-delugach  is no... The longer answer is based on Atlassian's admonition to not delete issues and other things. While it is indeed possible to, for example, write a groovy script that deletes an issue, there is always the danger that any one of us writes it "wrong" and leave the database/indexes/etc in an inconsistent state.

Rather, a better approach is to make sure you have a variety of "done" statuses including "canceled" or whatever. That way when (not if) people want activity reports, you get the full list including the ones that were abandoned but work spent on....