Automation – reverting unauthorized changes on multiple custom fields with different types

[nida ergenç]

Hi everyone,

I’m using Jira Automation to revert unauthorized changes to custom fields (based on Atlassian’s “).

It works fine when I use only one field, but when I add multiple custom fields with different types into the same rule, I start getting errors and data loss.

Example:

• Location (Select List – multiple) works alone

• When I add a Number field, Location becomes empty and audit log shows type conversion errors.

I have around 40 custom fields (selects, number, user pickers, text, date, etc.).

What is the best practice to revert unauthorized changes when many fields with different types are involved?
Should this be split by field type (separate IF + Edit actions)?

Any guidance would be appreciated. Thanks! 

[Rudy Holtkamp]

Hi @nida ergenç ,

You probably should convert the change string to a number for the failing field.

{{fieldChange.fromstring.asNumber}}

See here

[Bill Sheboy]

Hi @nida ergenç 

Yes, and...to the suggestions from @Rudy Holtkamp ...and without seeing the specifics of your rule's Edit Work Item actions:

A challenge for this scenario is knowing which field changed to understand which type conversion to use for reverting the value.  The changed field usually may be found from the entire {{changelog}} entry supplied to the rule, but that may be unreliable for cases when multiple fields change at once...and for fields with known defects in the changelog.

You describe wanting to handle 40 custom fields in the rule, and thus I expect this rule to be brittle / prone to errors from any simple typos (or when there is an Atlassian automation outage impacting rule triggering...as just happened last night).

I have two specific suggestions:

• Review your 40 fields, and perhaps group them by type, allowing you to either create separate rules by type, or bundle together the rule steps by type to reduce the chance of errors.
• Pause to understand why people outside of those specific teams / roles are changing fields which you do not want altered.  Perhaps have a team discussion to learn the root causes and the solve those, reducing how often this rule needs to run.

Kind regards,
Bill