Loop through all fields that were changed in a "Field Value Changed" automation trigger

[Carlos Matta]

Is there a method to iterate over all the fields that have been modified in a "Field Value Changed" automation rule?

For instance, if I have three fields set to be monitored by the trigger, I want to dynamically traverse the changelog to enumerate all the fields that have undergone changes. Ideally, it would look something like this:

"{{#changelog}}
Field: {{field}}
Changed from: {{fromString}} to {{toString}}
{{/changelog}}"

Thank you.

[Evgenii]

Hi, @Carlos Matta 

If I understood you right, you want to monitor some fields, and make changes, depending from what field was changed?

You can use IF/Else conditions, and configure them to look at field name. You can get it for smart value {{changelog.field}}. 
Something like this:

[Carlos Matta]

Thank you. That is essentially what I am doing currently, but I am looking for a method that simplifies the process when adding or removing a field, so I don't have to explicitly reference the field name.

[Bill Sheboy]

Hi @Carlos Matta -- Welcome to the Atlassian Community!

Regardless of what the documentation seems to imply, I hypothesize the Field Value Changed trigger only ever captures one field's changes at a time in the changelog (or fieldChange) smart values presented to rules when they run.  Ignoring that and the known defects in those changelogs for rules (e.g., list fields like Fix Versions have inaccurate changelogs in rules)...  Please see update below regarding the struck-through text.

UPDATE based on information later in this thread: when the edit is from a single REST API endpoint call, such as when a rule action changes multiple fields in the work item, there can be multiple entries in the changelog smart value available to the Field Value Changed trigger.  This may not apply for all fields as some likely require additional endpoints to update the fields.

You appear to want a rule which can generically handle changes to different fields for some type of notification / tracking.

Those other {{changelog}} attributes (such as the field name) cannot be iterated as you tried.  Instead I recommend a workaround:

• using Create Variable, save the entire {{changelog}} as text, perhaps named varChangelog
• then use text functions to extract what is needed from {{varChangelog}}, and...
  • You could then experiment to learn if that ever contains data for multiple field changes in one rule triggering.  Again, I do not believe it does so.

Kind regards,
Bill

[Carlos Matta]

Hello,

Yes, I have the "text" from the changelog and can store it in a variable (please see example below when modifying two fields, Description and Summary). Do you happen to know how I can parse the string to accomplish managing changes across different fields?

{
description=
[ChangeItemBean{
field='description',
fieldType='jira',
from='null',
fromString='Description before change',
to='null',
toString='Description AFTER change'}
],
summary=
[ChangeItemBean{
field='summary',
fieldType='jira',
from='null',
fromString='Summary before change',
to='null',
toString='Summary AFTER change'}
]
}

Thank you!

[Bill Sheboy]

First thing, how are you changing the issues leading to multiple entries in that smart value: the UX, another rule, the REST API, etc.?  I do not believe the UX supports changing both of those fields at one time.

Next, once the changelog smart value is stored in a variable, you could split() the value on the text "ChangeItemBean".  This will convert to a list of entries to parse (ignoring the one prior to the first text string):

https://support.atlassian.com/cloud-automation/docs/jira-smart-values-text-fields/#split-String-separator-

[Carlos Matta]

Hello,

When you perform an "Edit" on a story (regular Jira UI) and modify multiple fields simultaneously, it triggers a single "Field Value Changed" event. The changelog contains all the fields that were altered, which you have configured to capture. I will review the link you provided, thank you.

[David Nickell]

If your trigger is managed outside Atlassian then I recommend the following (and maybe within the Atlassian echosytem you can code your trigger this same way??)

• Make a REST API call based on a filter (or JQL) that returns issues modifed within x hours or days. 
• Include the expand=changelog parameter
• Loop through the field values checking for the ones you want

The API URL looks like this for a 1 day scan

https://ecosystem.atlassian.net/rest/api/3/search?jql=updated%3E=-1d&expand=changelog

And the changelog can be found in the Histories Object

The only potential "gotcha" is that the Changelog is paginated.  So if too many changes have been made, you'll have to make a few more changelog retrievals.

[Carlos Matta]

Hello, thank you for your feedback.

Firstly, I didn't quite understand the question regarding "trigger is managed outside Atlassian." This is an automation rule, and the trigger type is "Field Value Changed." Our goal is to track specific fields and send emails almost in real-time as changes occur. Currently, we manage this by specifying the exact field names, such as "changelog.summary." However, we aim to make our code more flexible, allowing us to add or remove fields without modifying the code. This is why we are seeking a way to loop through or parse the changelog without being dependent on which field has changed.