Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

What do you use "status" and "workflows" for?

Hi everyone,

Recently we had a bug where it wasn't possible to edit issue workflows for ideas (it's fixed).

Which leads me to the following question: what do you plan to use issue workflows for? Is it purely to manage issue statuses, or is there more to it?




Hello ,


Edit Issue workflows ??

Can you please provide more deatils. 




We use it as a high level status for our AEs.  Each Product Discovery ticket will be linked to an Epic when we're ready to work on it.  The Epic, stories and tasks will have more granular statuses so at a high level, the AEs can see whether the product discovery ticket is in the backlog, triaged, assigned to eng, in development, and completed. (not exact names of the workflow states but close enough) :)

Like Tanguy Crusson likes this

Thank you @quan. Based on this, I'm wondering: would it work the same way for you if you were using a "select field" configured with the list of high level statuses versus a "status" field where you can configure more complex workflows

Screenshot 2021-06-29 at 18.29.25.pngScreenshot 2021-06-29 at 18.26.40.png

Thinking a little more, we actually use the workflow a little (there might be two states a certain state could flow to).  Example is canceled or closed and we don't allow closed until someone gets past a certain workflow (released).  I think that's the only fork we have :)

Also hoping someday we can have automation to push the workflow to complete when the epic is closed automatically.

Having it as a select field could work but not sure if there's value changing it.  What's the rationale for a diff status field?

Like Tanguy Crusson likes this

Thanks, that's helpful. Status transition conditions thumbs-up

Re: automation - we will definitely support that. The way we are going to do it is via "Automation for Jira" (if you go in Project Settings, you'll see a "Project Automation" tab there - that's what I mean). This will help us ship the product with a bunch of pre-configured rules, e.g. "when all delivery tickets are done --> change the status of the idea". Which can then be extended/configured in each project, e.g. "and also update this other field, and send a slack message to people watching the idea".

I'm looking at the workflow engine and it's very heavy machinery, so what I'm trying to gauge here is if it's fit for purpose for discovery work - hence why I'm interested in use cases smile

got it, thanks for explaining.  I think because Product Discovery is "in Jira", it comes with a lot of expectations.  Having the status workflow feels like a standard assumption that it's there so if you ship PD without it, it'll probably be a feature request by someone :)

Like # people like this

Yeah I'd second quan's view. We use Jira because of the power of custom fields, configurability, workflows and a lot of that is expected even in any new 'product' inside of Jira I think. Otherwise it loses benefits and is at risk of someone just looking for another product management tool that integrates.

Like Tanguy Crusson likes this

Thank you. I totally I understand what you are both saying. Unfortunately as a product manager my curse is I have to ask "why?" smile This is not only about "should we support workflows or not?", but also, and more importantly IMO, "how do we support workflows and what jobs do we optimize them for?"

@Colin Goudie what are the specific benefits that workflows give you at the moment in Jira Product discovery, and how do you see that evolving? 

Workflows allow you to lock down where something can transition to.  It is super important in the development issues as you don't want something to "skip QA".  It is less necessary in this as it should be managed by Product Managers and is not usually auditable work.  I do still like that in a workflow, I can fully Close something out and not let it be reopened, etc.  but I don't think it will be too much of an issue in this project.  I do echo above though, we would need "Linked issues transitions to automatically change the 'Status' if you no longer use workflows"

Like Tanguy Crusson likes this

We want to use it to show our product process and how PM should think about getting and idea to development.

Like # people like this

I know I'm late to the party but we just gained access.  Our Product Operations and Product Management teams will be using the status & workflows as the phases of development and to automate notifications between the Ops and Mgt teams. 

Again, I just started but I'm looking at mirroring our Software Development Lifecycle 

Screening & Prioritization
Requirements Gathering & Analysis
Design & Validation
Implementation & Coding
Rejected / Abandoned
Pause / On Hold

Like Tanguy Crusson likes this

+1 on @Nina Thomas' comment! 

We plan on using workflows for our Product Development Life Cycle. 

Additionally, we would like to use automation to ensure:

  • all ticket statuses are updated accordingly 
    • linked issues from other projects are updated 
  • people are correctly notified (comment added to linked tickets)
    • we use JMWE for quite a bit, so ideally we could use it for Product Discovery as well
  • ensure required fields are filled out before transitioning to next status 
  • limit WHO can transition items between specific statuses 

Most of the above list of automation doesn't appear to be supported today, so I would be curious to understand what is coming for Workflow Rules! Happy to help explain use cases if need be. 

Like Tanguy Crusson likes this


Log in or Sign up to comment

Atlassian Community Events