Jira Automation Examples: 7 Workflows That Save Product Teams Hours

Jira’s automation engine is more powerful than most teams realize. But the examples in Atlassian’s docs are often too simple to be genuinely useful, and the advanced patterns take trial and error to figure out.

Here are 7 automation examples that product and engineering teams actually use, plus the AI-layer patterns that go beyond what rules can do.

1. Auto-transition Bugs Fixed by Engineering

The problem: A developer closes a bug in their branch, marks the Jira ticket as “Fixed,” and moves on. The QA engineer doesn’t know it’s ready for testing.

The automation:

Trigger: Issue status changes to “Fixed”
Condition: Issue type = Bug
Action 1: Transition issue to “Ready for QA”
Action 2: Assign issue to the QA lead
Action 3: Post a Slack message in #qa-queue: “Bug [issue-key] is ready for testing”

Why it works: Removes the handoff message. Bugs flow to QA automatically when devs close them.

2. Move Incomplete Sprint Issues to Next Sprint

The problem: At the end of every sprint, the scrum master manually drags incomplete issues into the new sprint. This takes 20-30 minutes and often gets forgotten.

The automation:

Trigger: Sprint completes
Condition: Issue is not Done or Closed
Action: Move issue to the next active sprint (or backlog if no active sprint)

Why it works: Eliminates a recurring manual task entirely. Incomplete work automatically carries forward.

3. Escalate High-Priority Tickets Left Idle

The problem: A P1 or P2 bug gets created, assigned, and then sits in “In Progress” for 48 hours with no updates. Nothing flags it until the customer complains.

The automation:

Trigger: Scheduled (every 4 hours)
Condition: Priority = Highest or High AND Status = In Progress AND Updated date > 48 hours ago
Action: Post Slack message to the PM and engineering lead: “[issue-key] has been In Progress for 48+ hours with no updates”

Why it works: Creates automatic accountability without requiring anyone to watch the board.

4. Auto-label New Issues by Source Keyword

The problem: Issues get created without labels, making filtering and reporting painful. Teams want to track issues by source (customer escalation, tech debt, internal request) but nobody remembers to label them consistently.

The automation:

Trigger: Issue created
Condition: Summary or description contains specific keywords (e.g., “customer request,” “escalation,” “technical debt”)
Action: Add the corresponding label

Why it works: Consistent labeling happens automatically at creation time, before anyone forgets.

5. Create Sub-tasks for New Stories Automatically

The problem: Every time a new user story is added to a sprint, the same three sub-tasks need to be created: Design Review, Engineering, QA. Doing this manually for every story adds up.

The automation:

Trigger: Issue created
Condition: Issue type = Story AND Sprint = active sprint
Actions: Create sub-task “Design Review” → Create sub-task “Engineering” → Create sub-task “QA”

Why it works: New stories arrive sprint-ready with their work broken down consistently.

6. Close Stale Issues After Inactivity

The problem: Backlogs accumulate tickets that were created months ago, were never prioritized, and now refer to problems that no longer exist. Nobody wants to go through them manually.

The automation:

Trigger: Scheduled (weekly)
Condition: Status = Open or Backlog AND Updated date > 90 days ago AND no active sprint
Action: Transition to “Won’t Do” or “Closed” AND add comment: “Closed automatically due to 90 days of inactivity. Reopen if still relevant.”

Why it works: Backlogs stay clean without a quarterly grooming marathon.

7. Sync Jira Status to Slack on Milestones

The problem: Stakeholders ask for updates on key features constantly. The PM has to check Jira, then post manually to #product-updates.

The automation:

Trigger: Issue status changes to “Done”
Condition: Issue has a specific label (e.g., “milestone” or “key-feature”)
Action: Post to #product-updates: “[issue-key]: [Summary] is now complete.”

Why it works: Stakeholders get automatic updates on the work that matters without anyone writing a status message.

The Limit of Rule-Based Automation

All 7 examples above work well for predictable, event-driven workflows. But they have one fundamental constraint: they can only react to things that already happened in Jira.

They can’t:

Read your standup notes and figure out which tickets need updating
Notice that a Slack conversation in #product surfaced a new requirement
Understand that a feature discussed in Tuesday’s call has three tickets that need to be created
Reprioritize the backlog based on what customers said in a meeting

For that, you need something that understands context, not just triggers.

The AI Layer: Automating the Input Side

Telos is an AI agent that fills the gap between what happens in your meetings and Slack and what ends up in Jira.

After every standup or planning call, Telos cross-references the meeting transcript against your existing backlog and proposes specific actions: which tickets to create, which ones to update with new context, which stale items to close, and what to reprioritize.

A summary arrives in your Slack channel: “Based on today’s standup, here are 4 actions I want to take in Jira.” You approve or reject each one. Approved actions execute immediately.

This isn’t a replacement for Jira automation rules - it’s the input layer that feeds them. The native rules handle transitions and notifications once things are in Jira. Telos handles getting the right things into Jira in the first place.