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; } } }

Get transition name with Automation

Vando Goncalves _e-Core_

Hey guys, how are you doing?

Here's what I need to do: from an incident or Service Request, to be able to create a Change or a Problem.

As I have just Automation for Jira, I'm addressing it this way:

I have 2 "general" transitions (the ones that go from any status to itself) on my workflow: Create Change and Create Problem.

Then, I have an automation which creates a change, with an IF to check is the status changed from it to itself ({{changelog.status.fromString}} == {{changelog.status.toString}}), but, this is triggering both automations.

I wanted to make an if clause, to check which transition was made.

Is this possible to achieve using smart values? Or any other if condition?

Accepted answers

Andy Heinzer

Hi Vando,

I'm well, thanks for asking. I see that you are looking to use some kind of smart value to distinguish these two different looped transitions. I do not believe there is any such smart value that will help in regards to being able to know the name of the transition called. The available smart values in Smart values - general simply do not extend to that info.

However I think there is a way you could make this work. I would actually look to adjust the workflow here. In Jira Cloud you could easily change the workflow for one of these transitions so that you could add a post function of type "Update Issue custom field" to one of these transitions. It could then change the custom field to some value that is unique to that transition. I recommend that this post function come before the one called 'Re-index an issue..' to try to make sure we avoid any race conditions.

You could then try to check for the existence of that custom field value on the issue to see which transition executed it. To make this work, you would need to also change the workflow of the other transition and give it a different value to set. That way the custom field could be overwritten by each of these transitions and in turn should only trigger the automation actions of the most recent transition.