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!

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

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!

Accepted answers

Rudy Holtkamp

Hi @nida ergenç ,

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

{{fieldChange.fromstring.asNumber}}

See here

All comments

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

Dave LIAO

@nida ergenç - adding to the above useful suggestions...

If there are times when no one should be editing any fields, consider setting the work item to read-only at those times.

You can have all fields set to read-only when a work item is in a specific status by using the jira.issue.editable property on that status. Read about that here: https://support.atlassian.com/jira-cloud-administration/docs/use-workflow-properties/

nida ergenç

Thanks for your all suggestions ! @Bill Sheboy @Rudy Holtkamp @Dave LIAO

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud