Atlassian's new automation pricing creates unintended cost explosions during bulk updates

Question

When performing bulk updates on tickets, it appears that automation rules are triggered as well. Since automation executions will soon incur additional costs, I would like to understand what strategies are available for handling this in the future.

For example, we recently added a new custom field and populated it for all resolved work items using a bulk edit. While the bulk update was running, it consumed around 80% of our automation quota within just a few hours. In this case, there was no real need for automation rules to be triggered again for those historical work items.

Is Atlassian planning to provide an option such as "Do not trigger automation rules" during bulk edits, similar to the existing "Do not send notifications" option?

Calvin · Answer

I am interested in this as well, or even if in the interim the filters in automations are updated so I can at least find automations that specifically are trigged from a field or certain status.

So I can see if any automations will be triggered before I do that bulk transition or field update without having to check every automation I have.

Stavros_Rougas_EasyApps · Answer

@flaimo what are you doing that it consumes so much so quickly? The sheer number of work items/fields or something with how it was created.

We build bulk content management tool for Confluence, and even our largest app Space Content Manager, that has a suite of tools, doesn't cause such issues. I'm curious what the underlying issue is.

Josh · Answer

I don’t know of a supported bulk-edit checkbox that suppresses Automation for Jira while still applying the changes. A bulk edit changes each issue, so rules listening for Issue updated (or a matching field change) can evaluate once per issue; “Do not send notifications” does not mean “do not fire automation.”

For backfills, I’d first tighten the rules: use a Field value changed condition for the fields that really matter, exclude the bulk-edit actor where appropriate, and add a guard/marker so historical issues are ignored. If the update is a one-off, temporarily disable only the affected rules, run a small test batch, then re-enable them and verify the audit log. For recurring backfills, a scheduled rule with explicit JQL is usually safer than an issue-triggered rule. Also check whether integrations or webhooks are consuming the quota, not just the visible rule count.