Atlassian introduces usage-based pricing: Time to rethink Jira Automation

Atlassian’s new usage model is not a minor accounting tweak—it is a direct warning that inefficient Automation designs can become an operational and financial liability. Atlassian has also announced its broader usage-based pricing model in its company announcement. Jira administrators and solution architects should treat this as a mandate to reconsider where automation logic is executed—not as an optional optimization.

Extra usage billing takes effect on December 3, 2026 and after that date automation usage will be measured in individual steps. Every executed trigger, condition, action, branch, and loop consumes part of the organization’s pooled allowance.

This does not make Atlassian Automation a bad solution. It remains a powerful way to coordinate work across spaces, products, and the wider Atlassian platform. But designs created under the previous successful-flow-run model may behave very differently when measured per step.

The broad-listener pattern

One of the most convenient Automation patterns has been to create a broadly scoped flow that listens for an event and uses conditions to determine whether anything should happen.

Consider this simplified flow:

1. A field changes.
2. A site-wide Automation flow receives the event.
3. Conditions check the project, work item type, field value, or other context.
4. The flow continues only if the event belongs to the intended process.

Perhaps the automation is only relevant to one space. Nevertheless, configuring it globally may have been easier than restricting the underlying process more precisely. Every relevant field-change event could enter the flow, while downstream conditions filtered out everything irrelevant.

Under successful-run accounting, executions that performed no action generally did not consume the allowance. This made broad listeners relatively inexpensive from a usage perspective.

That assumption no longer holds.

Under Atlassian’s step-based model, the trigger itself counts when it executes. If the flow evaluates a condition, that consumes another step. Atlassian explicitly includes NO_ACTIONS_PERFORMED and NO_MATCH among the statuses that consume allowance.

A site-wide flow can therefore consume steps for field changes occurring across many spaces, even though the intended business process exists in only one of them.

Strictly speaking, these events first consume the organization’s included allowance. They become a direct financial cost when that allowance is exceeded and extra usage remains enabled. If extra usage is disabled, reaching the limit creates a different risk: the affected flows stop until usage resets.

When one field depends on another

Updating a field based on other Jira information is a common variation of the same pattern.

For example, a calculated business value might depend on:

• Priority and due date
• Time-tracking information
• Service-management or governance data

Historically, this was often implemented as an Automation flow:

1. Listen for changes to one or more source fields.
2. Check whether the changed work item belongs to the relevant process.
3. Calculate the new value.
4. Write the result into another field.

This approach is intuitive and flexible. It can also be much broader than the actual business requirement.

Every source-field change that invokes the trigger consumes allowance. The flow may then evaluate multiple conditions before determining that no update is required. When several source fields can affect the result, multiple listeners or a broadly configured trigger may be necessary. Updating the destination field can also invoke other event-driven flows, creating further evaluations.

The important architectural question is whether the destination field represents independently managed business data or a value derived from existing information.

If the value is derived, storing and repeatedly updating it through an Automation flow may not be necessary.

Calculating instead of listening and writing

A simple derived value can require a trigger, conditions, calculations, and a write-back action every time its source data changes. But there is another option: Advanced Formula Fields provides calculated text and number fields whose values are derived from Jira data without consuming allowance.

Instead of listening for field changes and writing a result into a destination field, a formula defines the relationship between the inputs and the displayed value. Advanced Formula Fields can calculate values, aggregate information from related work items, and make the results available on work items, dashboards, and in JQL.

Typical examples include:

• Calculating a risk score from impact and likelihood
• Rolling up estimates or progress from child work items
• Deriving a KPI from several Jira fields
• Displaying information based on linked work items
• Formatting information for reporting

This removes the need for a separate field-change Automation flow in suitable cases. There is no broadly scoped listener that must evaluate every incoming event and no Automation action that repeatedly writes the calculated result.

Calculated fields are best when you need the current state of a dynamic value—for example, the sum of expenses tracked in subtasks—because they recalculate from the underlying Jira data. They are less suitable when you need to persistently record a one-time event, such as who approved a request, because that value should not be overwritten by later changes. In those cases, a workflow post function or Automation rule may be more appropriate, particularly when the value must be written at a specific transition or event.

The distinction is important:

• If the value should always reflect its underlying data, consider a calculated field.
• If an action must occur at a specific workflow moment, consider a post function.
• If a process must respond across projects or products, Automation may remain the natural choice.

Execute workflow-specific work where it becomes relevant

Before Atlassian Automation became the default choice for many Jira use cases, workflow post functions were a standard way to eliminate manual tasks and automate processes.

The architectural principle was straightforward: when a work item reaches a defined point in its lifecycle, execute the required process as part of that transition.

This approach is still highly relevant.

A post function does not need to listen to every field change across a site and then determine whether it cares. It runs when the configured workflow transition occurs—the precise point at which its business logic is required.

Jira Workflow Toolbox extends this model with powerful, low-code post functions capable of implementing complex automation. Depending on the process, JWT can create related work items, transition work, perform calculations, add comments, send notifications, call external services, or execute ordered sequences of conditional actions.

JWT post functions are not components of Atlassian Automation flows. Their executions therefore do not consume Atlassian Automation step allowances, and JWT includes unlimited execution of post functions.

This is particularly relevant when:

• The process is tied to a defined workflow transition
• Automation is required frequently or at scale
• Multiple actions must execute in a controlled sequence
• The automation replaces a recurring manual task
• The process is business-critical
• A broadly scoped listener currently discards most of the events it receives

Start by measuring intent against reach

The important question is not simply, “How many Automation flows do we have?”

A more useful technical review asks:

• How frequently is each trigger invoked?
• How often does the flow proceed beyond its initial conditions?
• How many executions produce an actual business outcome?
• Is the flow global even though its purpose is space-specific?
• Is the destination field genuinely stored data or a derived value?
• Does the process need to react to any event, or only to a workflow transition?
• Does the flow’s reach reflect an architectural requirement or historical convenience?

A flow that executes 10,000 times and produces 50 relevant outcomes deserves closer attention than one that performs useful work on nearly every invocation.

Global scope remains appropriate when a process genuinely crosses spaces, teams, or Atlassian products. The goal is not to eliminate global automation. It is to avoid consuming allowance—and adding operational complexity—for reach the process does not require.

Choose the right execution layer

A practical classification for each existing flow is:

1. Keep it global: The process genuinely requires site-wide, cross-space, or cross-product orchestration.
2. Narrow its scope: Automation is appropriate, but the flow listens to more events than necessary.
3. Optimize the flow: Conditions, branches, loops, or schedules can be simplified.
4. Use a JWT post function: The process should execute at a specific workflow transition.
5. Use Advanced Formula Fields: The result is derived from existing Jira data and does not require a listener-and-write-back flow.

Atlassian Automation, Jira Workflow Toolbox, and Advanced Formula Fields solve different architectural problems. The objective is not to declare one approach universally better. It is to execute each process where it is most precise, maintainable, and economical.

Focus automation on meaningful work

In an agentic-first world, the amount of automation will continue to grow. Atlassian is enabling increasingly powerful Automation, Rovo, and AI capabilities, and these features deliver real value. They also consume platform resources and increasingly come with measurable usage.

That makes architectural intent more important - not automation less valuable.

Before extra usage billing begins, review broadly scoped field-change listeners, global flows, flows that frequently stop after evaluating conditions, and flows whose primary purpose is keeping a derived field synchronized.

Where global orchestration is genuinely required, Atlassian Automation remains a strong fit. Where business-critical actions belong to a specific workflow transition, explore what JWT post functions can execute precisely and without Automation allowances. Where a value is derived from other information, consider whether Advanced Formula Fields can remove the event-driven flow altogether.

The focus should remain on what matters: reducing manual work while choosing the right technical mechanism for each process.