nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Revert issue back to previous status if field is not populated before transition

Apryl Harris_ud87de

Hello Community!

I need help with automation.

Use case:
When a user transitions a Bug issue and a certain field that is not populated, I want the issue to revert back to the status before the transition occurred and send an email to the user as to why the issue did not transition as expected (or why the status reverted back).

I see the below article but seems too complicated -

Can anyone help me?

Thanks!

How to transition to the previous status of an issue using automation rules in Jira | Jira | Atlassian Documentation

Accepted answers

All comments

Dirk Ronsmans

Hi @Apryl Harris ,

I wonder if it would not be easier to add validator (field required validator) to the workflow of your bug to block the transition if the fields is not filled in?

This would not send an email but would provide a message directly in the UI.

https://support.atlassian.com/jira-cloud-administration/docs/use-workflow-validators-for-company-managed-projects/

Apryl Harris_ud87de

@Dirk Ronsmans - I thought about adding a validator but I would have to touch every workflow in our instance, and we have a lot of different workflows. I was trying to do it with automation so I wouldn't have to touch every workflow.

Jakub Cieslak_njxwi3

There were some situations in my past that this mechanic was desired:

Check who performed a change (initiator)
If the initiator was on "allowed users" list, accept the change and do nothing
If the initiator was NOT on the "allowed users" list, revert the change and send an email with notification to initiator plus cc other colleagues who were in charge of the process.

So I am not saying what you want to achieve doesn't have use-case, but! If you can avoid all that drama of transitioning tickets back-and-forth between different statuses, did you consider just making the field mandatory in order to execute the transition?

This can be achieved in a pretty easy way:

Open the corresponding Workflow that applies to your use-case
OPTIONAL: If you are not using the new workflow editor yet (you probably are, as it is default), make sure you do, as it is more user-friendly!
Click on the transition that you are interested in (you do not have to limit yourself to only one transition), and click on the + button on the right context menu.
Use the "Validate a field" option.
Select the field you are interested in in the "For field(s)" part.
In the "Validate that field", depending on your needs, you might choose "Isn't empty" value.
Update other transitions as desired.
When done, on the Workflow overview, make sure that if the workflow is already used, you really want to introduce that change to all affected projects. Clicking on "Used by X project(s)" will show all projects that will be impacted by any change.
When sure that you want to proceed, click on "Update workflow" button.

Please also keep in mind that if you make a field mandatory to execute a transition, you should probably expose it on the transition screen, so user knows what must be filled.

Hope that helps! Cheers & Good luck!

Apryl Harris_ud87de

@Jakub Cieslak

I am trying to avoid having to touch every workflow as this is a global change that would apply to our entire instance for every project.

And I was trying to reduce the angst of requiring users to populate another field upon creating a Bug issue.

Thank you for the details.

Dirk Ronsmans

I've tried to replicate the use case but I fear that the "Isuse transitioned" trigger which you would need to use does not hold any value of the previous status.

I assume that is why the example in the documentation you linked first checks on the "field changed" trigger of the Status field and then saves the old value in some hidden custom field.

At the moment this seems to be the easiest solution.

Keep in mind that the custom field does not need to be visible on the issue (or even on your create/edit screens)

I get that having to add the validator to each workflow where it is needed is a hassle but it would still be the cleanest solution, otherwise the example rule seems to be the only option.

Apryl Harris_ud87de

yes. i think this is probably going to be the solution. but i was hoping some genius Community member had an easier native solution.

one can always hope...lol.

thank you,

Jakub Cieslak_njxwi3

Noted! In this case, if you really want to go for the Jira Automation, you could achieve it this way.

After you setup initial conditions for this Jira Automation (trigger/when to execute the rule, what issuetype you want to look for and so on), add "IF: Add a condition" and select "IF or ELSE: Add condition options" from the follow up.
Then, inside that IF branch, add component "THEN: Add an action" and pick "Create variable":
1. Variable name: transitionback
2. Smart value: {{#changelog.status}}{{from}}{{/}}
Then, below, add component "THEN: Add an action" and pick "Transition issue":
1. Destination status: {{transitionback}}
  
  Just start writing it, and then pick the drop down that activates smart value.
Add whatever else you want after that, e.g., send an email, add a comment or whatever else.

This is how the automation looks on my end, perhaps not the most performance-friendly approach, but it should work just fine.

Screenshot 2025-01-07 at 20.33.25.png

IMPORTANT:
Please remember that a transition back must be enabled/possible! If the Workflow does not allow it, it will fail.

Dirk Ronsmans

Great find @Jakub Cieslak !

I tried this earlier with the ChangeField.From but that didn't return anything. Going directly to the changelog is a clever way!

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud