📣 New improvements for Atlassian Automation Advanced Components!

[#1]

Hi Automation Community,

We recently introduced Branch with Conditions, a new way to build automation rules that make decisions and take different paths depending on what's happening real-time in your work items.

Today, we’re excited to introduce “Delay Until” Output Projections - a powerful feature that will let you know why an automation rule resumed, and what changed.

In this post, we'll walk through what Delay Until Output Projections is, the problem it solves, and how you can start using it today to build more dynamic, context-aware workflows. We’ll also share some of the improvements we’ve made to Branch with Conditions!

What are Delay Until Output Projections? 

The Delay Until component in Atlassian Automation lets you pause a workflow for a specific amount of time and/or until a specific set of conditions is met. It's a powerful tool that allows users to orchestrate their workflows with precision, ensuring every step happens at the intended time.

Until now, once a workflow with Delay Until resumed, the rest of your rule had no way of knowing how it resumed. We’ve heard your feedback that this often left customers guessing or building workarounds - Did the condition get met or did it time out? Did anything even change?

Delay Until Output Projections changes that. It gives every Delay Until component three built-in output variables that downstream steps in your rule can reference, making system behaviour explicit, stable and debuggable.

Output	Description
reason	Why the delay ended - whether the delay condition was met or whether the rule timed out.
resumedAt	The UTC timestamp of exactly when the Delay Until resumed.
payload	The raw work item changelog at the moment the Delay Until resolved.

These outputs are surfaced in a new Outputs tab on each Delay Until component. To use outputs, they must be added to downstream Rule groups as inputs.

How Delay Until Output Projections work

When you add or edit a Delay Until component in your automation rule, you'll now see an Outputs tab alongside the existing configuration options. This tab displays the three output variables ([reason], [payload], [resumedAt]) with their unique IDs, ready to be referenced downstream.

In any step after the Delay Until, you can use these outputs as smart values - plug them into conditions, actions, comments, or other components to branch your logic, log the outcome, or notify your team.

The most powerful combination? Add a Branch with Conditions component directly after your Delay Until, and use the [reason] output to automatically route your workflow based on whether the condition was met or timed out.

How you can use Delay Until Output Projections today

Example 1. Using Rovo agents to track context and capture insights as knowledge 

Combine Delay Until Output Projections with Rovo agents for powerful context tracking workflows. When issues are transitioned, pause the workflow until it’s completed. Then, let a Rovo agent analyse the context of what happened and capture it as knowledge that can be learned from.

Use the [reason] and expressions to intelligently route what happens next. If the condition was met, inspect the [payload] to generate a summary and document what happened in the right place. If it timed out, notify the initiator and update the priority.

In the example rule below, the logic for the branches is:

• On track branch
  • If the issue was transitioned within the due date threshold, the agent parses the payload to extract positive performance markers and then update the knowledge base with the agent’s findings for identified velocity indicators

• At risk branch

  • If the issue was transitioned outside of the acceptable timeframe, the agent parses the payload to identify potential bottleneck factors based on what happened, and then log this analysis to better detect warning signals for next time

• Fallback (timeout):

  • If the issue wasn’t transitioned within the set wait period, the initiator is notified and the priority is updated.

The [{{delayUntil_1.payload}}] output provides the full event data of exactly who did what at the moment the wait ended, allowing the agent to act as an informed translator rather than just guessing based on the current issue state.

Example 2. Approval gate with timeout escalation

Pause a workflow waiting for a manager to approve a request (e.g. transition a status or add a label).

The conditions are set in the Delay Until component, and you can use the reason output to branch your workflow:

• If [reason] = met: proceed with the approved path → assign the work, notify the team, kick off next steps.

• If [reason] = timeout: escalate automatically → notify the manager's lead, flag the ticket as overdue, and reassign.

Using the delay’s outputs in the branches removes the need to duplicate the same conditions per branch, allowing it to inherit any changes in the conditions upstream.

Example 3. SLA breach detection and reporting

Use Delay Until to wait for an issue to be resolved, with a timeout set to your SLA target. When the Delay Until resumes:

• If [reason] = timeout: the issue was not resolved in time → trigger a breach notification to your team and log the [resumedAt] timestamp for SLA reporting.

• If [reason] = met: the issue was resolved before the SLA deadline → log the [payload] . The payload captures exactly what changed that caused the workflow to resume, which is valuable in validating the flow and essential for compliance and audit log trails.

Branch with Conditions - A quick recap

Branch with Conditions lets your automation rules take different paths based based on real‑time context like priority, customer, status, or request type. Instead of writing multiple separate rules to handle different scenarios, you can build one smart rule that evaluates conditions and routes work accordingly.

For example: a single rule can automatically route a high-priority bug to the on-call engineer, a medium-priority bug to the team's backlog, and a low-priority one to a triage queue - all in one rule.

What's new in Branch with Conditions

1. Execution Mode: "All conditions" or "At least one

Previously, when you set up conditions on a branch, all conditions always had to be true for that branch to run. We saw many of you ask for more flexibility, and you will now be able to choose how your branch evaluates its conditions:

• All conditions match (AND logic) - the branch only runs if every condition is true.

• At least one condition matches (OR logic) - the branch runs if any one of the conditions is true.

2. Smarter Conditions: Use any value! 

In the first release, branch conditions were limited to work item fields - things like Priority, Status, Assignee, etc. This was a great starting point, but many of you wanted to write conditions based on the outputs of previous automation steps.

Now, the Branch with Conditions step supports any available smart value, including:

• Smart values from your Jira or JSM work items

• Variables you've set earlier in the rule

• Outputs from previous automation components including the Delay Until component (See above)

• Outputs from Rovo Agent responses

Try it now - we'd love your feedback!

Delay Until Output Projections and Branch with Conditions is now available to all Atlassian Automation customers on Jira and Jira Service Management Premium and Enterprise plans.

We can't wait to see the smarter workflows you build with it. If you have questions, ideas, or want to share how you're using it, please share in the comments below!

FAQ

Q: Do I need to do anything to enable it?
A: No action required. Both of these components can be found when building or editing an automation workflow under ‘PLUS: Add an advanced component’ section. For the Delay Until component, you’ll see the new Outputs tab automatically.

Q: Can I reference these outputs in any step after the Delay Until?
A: Yes. reason, payload, and resumedAt can be used as inputs in any subsequent action, condition, or component in the same rule, just like any other smart value.

Q: What happens if I have multiple Delay Until components in one rule?
A: Each Delay Until has its own unique output IDs so you can reference them independently. Be sure to check the Outputs tab to confirm you have the correct reference. Naming each component clearly will help keep things readable.

Q: Where can I learn more about the Delay Until component?
A: Check out the Atlassian Automation advanced components documentation for full details.