Automation triggering field change history entries for fields that were never edited/touched

[Mawaddah Hasnan]

I have an automation rule that performs a series of actions including adding a comment, sending an email and transitioning to another status.

In the customer form, a user made a change only to the Remarks field and clicked Submit to transition the issue. However, the audit trail (All Activity) shows that multiple other fields were also "updated" at the same time which are fields the user never touched.

Question:

Why does Jira create history entries for fields that were not modified by the user? The only action taken was editing Remarks and submitting.

This makes it difficult to track genuine field changes for audit purposes and it triggers other automation rules that are set on field value changes.

Any insight would be appreciated. Thanks

[Germán Morales _ Hiera · Accepted solution]

Hi @Mawaddah Hasnan , those aren't real edits. On submit, the transition screen re-saves every field it carries, and rich text or re-serialized field types get written back slightly differently, so Jira logs them as changed even though only Remarks was touched. Quick check: if the history author is the submitter it's the screen, if it's Automation for Jira the rule is writing them.

• Trim that transition screen or request form to the fields that truly need editing there.
• In the downstream rules, gate the trigger with a condition that only continues when {{fieldChange.fromString}} differs from {{fieldChange.toString}}.

[Mawaddah Hasnan]

Thanks for the clarification. Your second suggestion really helps for current situation. These fields are in a portal form instead of a transition screen, so trimming the screen is not an option as any changes made there would not reflect on existing forms. Thank you again

[Ash H_]

Hi @Mawaddah Hasnan 

I'm Ash from Appfire's Expert Services team. 

You might want to consider JMWE to help. 

Jira Miscellaneous Workflow Extensions (JMWE) provides advanced post-functions that allow you to perform field updates with much higher precision than native automation. For instance, JMWE post-functions like "Set field value" or "Copy field value" can be configured with conditional execution (using Jira expressions or Groovy) to ensure the update only occurs under very specific circumstances. This level of control helps prevent unnecessary field history noise by ensuring that a field is only "touched" when a genuine change is required by your business logic. It’s a powerful way to keep your issue history clean and meaningful for your team. 

Hope it helps,
Ash

[Sebastian Krzewiński]

Hi @Mawaddah Hasnan 

As I understand rule should be triggered when change is done in certain field and now it is triggering for any field on form, right? Can you share a screenshot with rule trigger? 

Regards,

Seba

[Mawaddah Hasnan]

Hello, thanks for the response.

The rule is not set to trigger on any field changes, according to my screenshot below. This rule is fired the same time when the user clicked on "Submit" 

These are the fields it marked as "edited by user" 

The other rule that i mentioned that are set on field value changes is a separate rule that triggered because it detects field changes which is this one:

Which is not supposed to run because the user did not edit those fields. The only action the user took was editing Annual Review Remarks and clicking Submit to transition the issue.