How do multiple conditions count towards the new automation step usage?

Dayna Portillo

After receiving the notification about Atlassian's new automation pricing, I am on a mission to make my automations more efficient so we don't exceed our limit.  I am a bit unclear on how Atlassian is defining a "step" as it relates to conditions.  If a condition (yellow) step/node has multiple criteria that are connected by ANDs/ORs (JQL or otherwise), does that count as a single step or one step per criteria?  Similarly, within a trigger step, does each criteria/condition within that trigger count as its own step or is the entire trigger counted as a single step regardless of the number of criteria within it?

 

I found this article to be somewhat helpful but it did not fully answer my question regarding conditions: https://community.atlassian.com/forums/Jira-Cloud-Admins-articles/Automation-steps-start-billing-on-3-December-Your-allowance-what/ba-p/3285795

 

Does anyone have any firm information on this topic?

Sami Shaik

@Dayna Portillo , 

@Gor Greyan has the principle right and I want to add the source and the two cases it does not cover, because the difference between "I think" and "the doc says" matters when you are budgeting for December.

The unit is the component that executes, not the criteria inside it. Atlassian's definition: a step is a trigger, a condition, an action, an if/else branch, or one iteration of a loop, counted when that component finishes with a charged status (how usage is calculated). So:

• One condition component with three criteria joined by AND or OR is one step, whatever the criteria evaluate to.
• One trigger with several criteria (a field-changed trigger watching four fields, a scheduled trigger with a JQL) is one step per firing.
• Three separate condition components in a row are three steps, and that is the case where rule design changes the bill: put the cheapest, most selective condition first, because a failing condition stops the run there and the components after it are not executed and not charged.

A failing condition still charges for itself. The charged statuses are SUCCESS, NO_ACTIONS_PERFORMED, SOME_ERRORS, ABORTED and NO_MATCH. A rule that fires on "Work item updated" and fails its condition 95 percent of the time pays one trigger step plus one condition step on every rejected event. That is the single largest source of unexpected steps I have seen, and the fix is a narrower trigger (Field value changed for the specific field) rather than a broader trigger with a condition behind it.

Not charged: system and synthetic components Atlassian runs on your behalf, THROTTLED runs where nothing executed, and system-side errors. Rovo agent actions inside rules bill as Rovo credits, not steps.

Verify it on your own rules rather than take anyone's word, including mine: open a space's automation list, More actions, View performance insights (or the global automation page for every space), which shows executions per rule and their outcomes (performance insights). It counts executions, not steps, so multiply by the number of components that ran; for a rule whose condition fails most of the time that is executions times two. Compare the total with the Automation steps meter in Atlassian Administration, Insights, Platform usage, and the arithmetic will tell you whether your reading matches the meter's.

@Trudy P Claspill  link is the same page; the section titled "What counts as a step" is the one to bookmark. I wrote up the allowance table, the charged statuses and the five rule shapes that burn steps in one place yesterday, if the long version is useful: Automation steps start billing on 3 December.