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

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Can I add a step prior to "create" in a workflow

Can I add a step prior to "create" in a workflow that would essentially serve as a request to create a ticket? 

The user story is that we need a way to request a release ticket and fix version that can be tracked with the project it pertains to, but restrict release ticket creation to a group. 

We do have several plugins including scriptrunner, JMCF, and JSU Automation Suite., as well as JSD




3 answers

2 accepted

1 vote
Answer accepted
Joe Pitt Community Leader Jan 22, 2020

No. The issue number is the primary key in the DB, so until the issue is created there is no way for the database to track it. I suggest you have a workflow step out of the Open status to close the ticket if not needed. Don't delete it. 

Thanks Joe ~

I realize that the ticket is created either way, we just need a way to keep the release from progressing if it is not a good fit or has conflicts with other releases. Its more about renaming transitions and statuses in this case. 


0 votes
Answer accepted

Yes, and no.

Yes, because you can have any status you want as the landing point for "create"

But, no, because once you create the issue, you have a created issue.  There's no "request to think about maybe creating something".  You've created it.

A lot of places do do workflows that have:

  • Create -> "We think we need" -> "Open"
  • Create -> "We think we need" -> "No you don't, closed"

But you can't work on an issue that isn't there.

Thanks Nic~

I get that the issue is actually created, and in 99% of cases, the ticket would deploy - so I like your suggestion of having the option to reject after creation. We do this for most other tickets (bc we do not delete tickets), though the reasoning is different. 

So I could make only the key fields available to the requestor on the create screen for that issue type, call the first Transition "Request Release", then auto-assign to release team at that transition (we have several AD groups as assignees) . A release engineer could pick the ticket, assign it to themselves, and either continue with the release creation process or reject it if the requested release is not viable or has too many conflicts. 

If the release request is rejected, the requestor could reopen it with a new set of dates and it would repeat the process. The next transition (our folks call them "buttons") would be "release approved", which could notify the requestor to associate dev tickets with the release, and then it would progress as usual

Thanks again, I think this will work!

Well technically its the second transition, "Create" being the first. :-) 

Yes, this will work.  I over-simplified, missing out

"open" -> rest of desired workflow

"No you don't, closed" should have an option to push it back to "we think we need", ideally with some way to qualify or justify why it should be don.

Like StephanieC likes this

You could also solve your requirement by having a separate issue for the Request in another project (where everybody has access).

When the Request issue is approved, a new Release issue is created. To achieve this you can use the 'Create A Linked Issue (JSU)' post function in the Approve transition of the Request.


You can find the documentation of that post function here:


And some similar use cases:

Suggest an answer

Log in or Sign up to answer

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you