RFC-146: Conditional execution for Jira workflow post functions

General Request for Comments (RFC)
, , , ,
1

RFCs are a way for Atlassian to share what we’re working on with our valued developer community.

It’s a document for building shared understanding of a topic. It expresses a technical solution, but can also communicate how it should be built or even document standards. The most important aspect of an RFC is that a written specification facilitates feedback and drives consensus. It is not a tool for approving or committing to ideas, but more so a collaborative practice to shape an idea and to find serious flaws early.

Please respect our community guidelines: keep it welcoming and safe by commenting on the idea not the people (especially the author); keep it tidy by keeping on topic; empower the community by keeping constructive. Thanks!

Project Summary

  • Publish: 15 September, 2026

  • Discuss: 16 September, 2026 - 2 October, 2026

  • Resolve: 8 October, 2026

Today, Jira workflow post functions run unconditionally. If a post function is configured on a transition, it fires every time that transition executes.

We will add an optional Jira Expression to native post functions so a workflow admin can say “only run this action when…” without restructuring the workflow. Jira will evaluate the expression during the transition before the post function executes. If it evaluates to false, the post function does not run.

We plan to release this to Beta / EAP participants around late October or early November 2026. Initial rollout will focus on native post functions such as system:update-field, system:copy-value-from-other-field, and system:trigger-agent, with support through our public workflow APIs.

Our intent is to expand native conditional execution to Forge and Connect post functions, and potentially validators as well in the future. Before doing so, we want to gather feedback from partners and developers to gather feedback on extension and execution needs that can best serve your apps.

This RFC is relevant if your app provides workflow post functions, conditions, or validators, or if it offers its own mechanism for conditionally gating workflow behavior.

Problem

To add conditional behavior to a post function today, a workflow admin must express the condition in the workflow’s structure rather than the rule. In practice that means one of:

  • splitting one logical transition into several near-identical transitions, each with a different condition and set of post functions;

  • adding intermediate statuses purely to route work items to the right actions;

  • using a Marketplace app that offers gating on its post functions.

The result is workflows that are much larger than the process they model, with the same action configured in several places and no single place to change it.

Workflow agentification makes this more pressing. In 2025 we introduced the Trigger Agent post function, which lets an admin invoke an agent when a work item is created or transitioned. Uptake has been steady, and unlike Update Field, an agent invocation incurs customer cost in tokens and credits. Running one on every transition execution, when the admin only wants it for bugs or when the ticket has certain fields filled, wastes billable resources. We’ve seen admins build elaborate transition graphs solely to gate an agent.

Proposed Solution

A post function may include an optional conditionExpression parameter. Jira evaluates it during the transition, immediately before the post function would execute. If it evaluates to true, the function runs. If it evaluates to false, the function is skipped and the transition proceeds normally.

If the expression errors, fails validation, or cannot be evaluated, we treat the result as false and do not run the post function.

For example, this configuration sets Priority to High only when the work item is a Bug.

  • ruleKey identifies the native post function being configured.

  • parameters holds that function’s settings, as it does today.

  • conditionExpression is the gate.

{
  "id": "fee457e7-bdbe-4073-aebb-b067185d224d",
  "ruleKey": "system:update-field",
  "parameters": {
    "field": "priority",
    "value": "High",
    "conditionExpression": "{\"expression\":\"issue.issueType.name == \\\"Bug\\\"\"}"
  }
}

Why the expression is a JSON-encoded object rather than a bare string

conditionExpression wraps the expression in a JSON object intentionally: we expect to add sibling properties over time (a human-readable description, configuration metadata referencable within the expression). It’s easier to add fields inside a structure than to define parallel parameters each time.

Scope of the expression

We intend to keep this scope narrow:

  • Jira Expressions only. No other languages or dialects.

  • Transition-time data only. The expression can access the work item, project, transition, and user. It cannot access data unavailable at transition time.

  • Evaluated inline, on Jira’s side, before the post function executes — not after the transition completes or before it starts.

  • A simple editing experience. A basic builder for common conditions, AI assistance to draft expressions, and direct expression entry for advanced cases.

jex-editor
jex-editor1724×672 33 KB

basic-editor
basic-editor1790×1190 109 KB

Relationship to Marketplace apps

Many apps provide a form of conditional gating for post functions today. These typically run as part of hooks that fire after the transition. Apps offer richer authoring experiences, support alternative languages and allow deeper integrations with data or systems that Jira does not have access to during a transition.

As such, our main concern is confusion rather than competition. With both a native conditional gate and an app conditional gate, a post function may have two different reasons for not executing with configuration over two different surfaces once we enable this for Forge or Connect apps. Differences between the native configuration and the app’s configuration can may also create some degree of confusion or lead customers to wonder which one to use and when.

We do think it’s worth considering how they both can work together, particularly where a decision can be made during a transition and potentially cut out unnecessary invocations where an app may have nothing to do if it was triggered. This aligns with RFC-143: Reduce Forge invocations from bulk operations. We want to work with app authors to get the details right and ensure native gating is useful alongside app capabilities.

Asks

We welcome any reactions to this RFC. We’re especially interested in:

  1. What conditional gating do your apps provide for workflow post functions today, and how would a native condition could sit alongside it? Would it be complementary, redundant, or confusing?

  2. Where do users get confused when configuring conditional post functions, in Jira and in apps? What have you learned from supporting them?

  3. What tools would help users manage, validate, test, or troubleshoot these expressions? Would an extension point around expression authoring or validation help?

  4. Would you want a native conditionExpression to gate your app’s post function so Jira skips the invocation entirely?

  5. Is treating a failed or erroring condition as “do not run” the right default? Would you want an opt-in “run anyway” behavior of , and when?

  6. Is transition-time data (work item, project, transition, user) sufficient for the gating customers ask for? If not, what else would they need to reference?

  7. Does the JSON-encoded conditionExpression shape cause problems when reading or writing workflows via the REST API?

1 Like