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

Jira Automation: Getting second-to-last status of an issue

A_ Boehme _Communardo_

For my current automation I want to make sure that my current issue's second-to-last status was X.

I have found that you can get the last status using the changelog:

{{#changelog.status}}{{fromString}}{{/}}

If the changelog is a bunch of text, shouldn't it be possible to get the second-to-last status too with the right syntax? Unfortunately I'm not clear on the syntax.

Thanks for any help.

Accepted answers

Bill Sheboy

Hi @A_ Boehme _Communardo_

First thing, what problem are you trying to solve? That is, "why do this?" Knowing that may help the community offer additional suggestions.

Without seeing your entire rule for context, to get the next-to-last value changed for any field, I believe there are only three methods with automation rules...all with limitations:

REST API and the Send Web Request action
- Although the changelog contains most of the changes to work items, it cannot be easily accessed from automation rules except to get the previous and current values.
- A workaround for your scenario is to use the Send Web Request action to call the Bulk Fetch Changelogs endpoint, filtered on the Status field. This could return up to 1000 value changes, and so if you have more it will not help.
- Once the endpoint returns, the values will be in changelog order, oldest to newest. Thus, using the count of items in the list, one could go back one (or two) items to get the record:
  - If you go back one, the "from" or "fromString" will be what you want
  - If you go back two, the "to" or "toString" will be what you want
Build your own Forge app with a new rule action
- Using the REST API approach described above, build a new rule action which could return the value
- This seems even more complex than the REST API approach to solve this, and introduces additional risks to your rules...and creates maintenance work for the app
Extra custom fields
- This approach works for future changes and not ones that have already happened
- Create a couple of custom fields to store the -2 and -1 Status values
- Using another rule triggered on work item transition, update those fields to cascade the values
- Limitations / Risks are: extra fields, people tampering with the values, and rules like this can be brittle due to all the ways status could change and the possibility of an automation outage preventing rules running when they should

Kind regards,
Bill

All comments

Joseph Chung Yin

@A_ Boehme _Communardo_ =

The changelog status is always in the format {{changelog.status.fromString}} to {{changelog.status.toString}}.. Maybe if you can provide more information to allow us to assist you further.

What is your current output from your smartvalue?

Best, Joseph

A_ Boehme _Communardo_

@Joseph Chung Yin Thanks for your reply.

Let's say the issue in question went through the following status: To do > In Progress > Closed. Currently the issue is in status Closed.

This means

{{#changelog.status}}{{fromString}}{{/}}

evaluates to "In Progress".

{{#changelog.status}}{{toString}}{{/}}

evaluates to "Closed".

I am looking for the expression to get the result "To do" (in the scenario described as an example here).

Sam Okell

Given you are on Enterprise, you could get this from Atlassian Analytics.

The jira_issue_history table contains all status changes, and anything with no end date means that this is the current state.

For each state it tracks the previous and current value.

Therefore, you could find the status change with the latest end date, then the previous value field would give you your answer:

Field | Start Date | End Date | Previous Value | New Value

Status | 01/01/2026 | 05/01/2026 | To Do | In Progress

Status | 05/01/2026 | | In Progress | Done

Something along the lines of:

Select jira_issue_history_id

From jira_issue_history

Where 'End Date' Is Not NULL

And Field = 'Status'

And 'End Date' = (

Select Max ('End Date')

From jira_issue_history

Where 'End Date' Is Not NULL

And Field = 'Status')

Just some more stuff around that to give you details, but should get you there.

Outside of this, I can't think of any way to do this through automation. The API may be an option, but not overly convinced it would be any better.

Joseph Chung Yin

@A_ Boehme _Communardo_ -

Try this out, maybe it can help you to iterate8 looping through the status change log

{{#changelog.status.items}}
Status changed on {{created}} from "{{fromString}}" to "{{toString}}"
{{/}}

Hope this helps.

Best, Joseph

Bill Sheboy

Hi @A_ Boehme _Communardo_

First thing, what problem are you trying to solve? That is, "why do this?" Knowing that may help the community offer additional suggestions.

Without seeing your entire rule for context, to get the next-to-last value changed for any field, I believe there are only three methods with automation rules...all with limitations:

REST API and the Send Web Request action
- Although the changelog contains most of the changes to work items, it cannot be easily accessed from automation rules except to get the previous and current values.
- A workaround for your scenario is to use the Send Web Request action to call the Bulk Fetch Changelogs endpoint, filtered on the Status field. This could return up to 1000 value changes, and so if you have more it will not help.
- Once the endpoint returns, the values will be in changelog order, oldest to newest. Thus, using the count of items in the list, one could go back one (or two) items to get the record:
  - If you go back one, the "from" or "fromString" will be what you want
  - If you go back two, the "to" or "toString" will be what you want
Build your own Forge app with a new rule action
- Using the REST API approach described above, build a new rule action which could return the value
- This seems even more complex than the REST API approach to solve this, and introduces additional risks to your rules...and creates maintenance work for the app
Extra custom fields
- This approach works for future changes and not ones that have already happened
- Create a couple of custom fields to store the -2 and -1 Status values
- Using another rule triggered on work item transition, update those fields to cascade the values
- Limitations / Risks are: extra fields, people tampering with the values, and rules like this can be brittle due to all the ways status could change and the possibility of an automation outage preventing rules running when they should

Kind regards,
Bill

A_ Boehme _Communardo_

Thanks for the replies everyone! I am seeing this is a more complex ask than I initially thought. As a matter of cost-benefit efficiency, I will use a different solution and use two separate automations with separate triggers. This way I don't have to distinguish which earlier status an issue had.

Welcome!

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

Quick Links

Find more posts tagged with

cloud

smart-value

jira-service-management-cloud

jira-service-management

jira-automation