Are Jira Service Desk workflow properties still needed?

[Andrew Culver]

We're setting up Service Desk and would like to use our own workflow, rather than the default workflow.

I came across this KB article: https://confluence.atlassian.com/jirakb/workflow-properties-in-jira-service-desk-701596238.html

It describes setting up various properties to the steps, transitions, and the workflow itself in order to get the automatic transition to work properly when a customer comments on an issue.

But at the top of the KB article it says:

We do not recommend manually configuring your JIRA Service Desk workflow properties. We introduced automation rules in JIRA Service Desk 2.4, which can be used to automatically transition issues when a comment is added.

Does this mean these workflow properties are no longer needed and we should be using automation rules instead of the workflow properties? Do I need to bother with these properties at all?

If so, why do the workflow properties still exist in the default workflows that come bundled with the latest version of Service Desk (3.12) if this was changed way back in SD 2.4? Why does this KB article (for Jira 7.9) still exist instead of simply directing users to an article about setting up automation rules?

Thanks

[laralg]

Hi Andrew,

Sometimes workflow properties are usefull. I personally like the one that limits the Resolutions you can choose, so when and issue is resolved I hide the "Declined" resolutions and the ops-bar where I can reorder the buttons in my workflow.

I understand Atlassian does not remove that infor as everyone is not updated and sometimes they are still usefull, but Automation rules are often better since you do not need to be a Jira Admin to modify them.

Regards.

[Jack Brickey]

Agree w/ Lara here and w/ Atlassian. While changing the Properties are not for the feint of heart there are times where they can be quite useful. The challenge comes in getting the property to work the way you want exactly, remembering that it is there and being able to remember to investigate that area when troubleshooting an 'unexpected' behavior down the road. It will certainly make it more challenging for a new incoming Jira Admin to dig thru the bones and understand how the system was configure but if they are good they will find it.

[Ronald Vallenduuk]

Never an answer from the mothership. Typical.

I have the same question; I found that article while trying to figure out what all those properties on the service desk workflow transitions are for.

I don't like the out of the box service desk workflows and want to customise them but before I get the hacksaw out I'd like to know what I'm working with.

[Victor Mutambuki]

Andrew,

There are 7 basic workflow properties in JIRA. Properties are used to implement restrictions on certain steps or transitions of a workflow. These properties dictate for example; 

1. Who can edit issues.
2. Determine the order of your transitions on your issues and so forth.

You can choose to use them or not. Depends on your organizational needs.

Thanks

Victor

[Andrew Culver]

Hi Victor,

The 7 basic workflow properties you're mentioning are common to Jira. I'm talking specifically about the Service Desk workflow properties described here: https://confluence.atlassian.com/jirakb/workflow-properties-in-jira-service-desk-701596238.html

[Victor Mutambuki]

Answer,

I see. In our line of work, we've not encountered situations that required the use of Service Desk  Properties. I think Waiting on Customer and Waiting for Support come with built in properties. As for the rest, that would be upto the user.

thanks

Victor

[Victor Mutambuki]

Andrew,

These properties are set on the JIRA side.

Victor

[Andrew Culver]

What do you mean?