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

Automation: Open all On Hold Issues

I have this automation set up to open all on hold issues each weekend.  A bit of a back story, each day I have a filter sent to me to display all my open issues (open or in progress) that are due during this sprint.  If an issue is resolved or on hold it won't be sent in the filter.  Each weekend I have all on hold issues moved back to In Progress, so that Monday I can review the issue and see if I can start working on it or not.  This forces me to be realistic about the issue - is it something I can actually complete during this sprint or do I need to move it to the next Sprint?

Now on to the automation:

I originally had it using the CRON expression but once Automation updated to use an easier Scheduled format I switched to that :D

FireShot Capture 119 - Project automation - Jira Cloud -

Every Sunday at 9a it will run a JQL query: all issues in the specific project I'm working on that are on hold status, then it will transition the issues to On Hold and remove the text from the "Hold Reason" field.


Hi @Kristin Lyons 

Thanks for this information.  I wonder...

  • Using this method wouldn't you lose visibility to how long and how often issues are on-hold?  Could checking the aging of on-hold issues provide a better approach?
  • When issues are on-hold often enough to need a status in the workflow, that may be a symptom of bigger issues, such as high work in progress (WIP) counts, changing priorities, too many dependencies/hand-offs of work, etc.  What do you think?

Thanks, and best regards,

Hi @Bill Sheboy  Those are some good points that I might implement!  I really like the idea of not having an On Hold status in the workflow but I'm not sure if that's feasible.  Much of my work is dependent on others' schedules.  I do however like the idea of tracking how long and how often issues on are on hold.

Like Bill Sheboy likes this

Yes, and...maybe try a short retro/ponder for on-hold issues learn what is preventable and if there are patterns to on-hold issues.  Even when you cannot yet resolve the causes such as others' schedules, knowing it is gonna happen will improve visibility to you and stakeholders.

Carlos Faddul Community Leader Jul 26, 2021

@Kristin Lyons

in the trigger Scheduled, you can use the JQL condition as a filter to execute the automation and unmarked "Only include issues that have changed since the last time this rule executed"

I hope I helped you.

If this post was helpful, mark it as Accepted solutions, so you can help others who may have the same difficulties.

If your question has not been resolved, please post again with more details.


Log in or Sign up to comment