Blog · 25 September 2026

Automate Jira ticket creation: five triggers compared

To automate Jira ticket creation, first decide what should cause the ticket to exist. Jira Cloud can create a ticket for you in five broad situations: when another ticket is created or changes, when a form is submitted, when an outside system calls a webhook, when a new space is created, and on a schedule. The first four are reactions to an event and belong in Jira Automation. The fifth is different, because nothing happens to set it off except the calendar, and that is where most teams lose time: the weekly report ticket, the monthly access review, the quarterly patch window. This guide walks through each trigger, the job it suits, what it costs as of September 2026, and when the manual way is still the right answer.

Start with the question: what causes the ticket? #

Most "automate ticket creation" projects stall because they start from the tool rather than the cause. Write down the tickets your team creates by hand in a normal month, and next to each one, write what prompted it. You will usually find three groups:

• Something else happened in Jira. A bug was marked as needing a fix in another team's project, an epic was created and needs its standard child tickets, a story moved to Done and QA needs a ticket.
• Something happened outside Jira. A customer filled a form, a monitoring tool raised an alert, a build failed.
• Nothing happened. It is simply that time again. Monday's triage, the first-of-month billing reconciliation, the quarterly disaster-recovery test.

The first two groups are event-driven. The third is time-driven, and it needs a different kind of tool, because an event-driven rule has nothing to react to.

The five triggers at a glance #

Atlassian's own list of Jira Automation triggers covers all five situations, read in September 2026. This table maps each one to the job it usually does.

The rest of this page takes them in that order.

1. From another ticket: created, transitioned, linked #

The most common automation is a ticket that follows another ticket. In Jira Automation you pick Work item created or Work item transitioned as the trigger, add a condition that narrows it to the right ones (a label, a type, a project), and finish with an action that creates the new ticket. Smart values let the new ticket copy the summary, reporter or components of the one that set it off.

Good uses:

1. When an epic is created, add its standard child stories.
2. When a bug in the support project is marked as confirmed, create a linked bug in the engineering project.
3. When a story reaches Done, create a documentation ticket for the technical writer.

If what you actually want is the same subtasks every time, the Jira subtask template guide compares four ways to get them, and Jira automation examples has worked rules of this shape.

2. From a form: requests without the typing #

Jira's forms let a requester answer a fixed set of questions, and the Form submitted trigger runs a flow when one is sent. Atlassian notes a detail worth knowing before you build: if you select several forms, the flow only runs when all of the selected forms on a work item are submitted. For a request intake where each form is independent, use one flow per form.

This is the right tool when a person outside your team starts the work and you want their answers in a consistent shape: access requests, equipment orders, content requests.

3. From another system: the incoming webhook #

When the cause lives in another product, such as a monitoring alert, a failed build, or a signup in your own app, the Incoming webhook trigger gives you a URL. Atlassian's description is short:

The flow will run when a HTTP POST is sent to a specified webhook URL.

The sending system posts to that URL, and the flow creates the ticket from the data it received. This takes a little setup on the sending side, but once it works you stop copying alerts into Jira by hand.

4. From a new space: starter tickets #

The Space created trigger fires when a new space appears. Atlassian suggests it for creating a set of default work items that should be in every space. Teams use it for a kickoff checklist: set up the board, invite the stakeholders, write the brief. It runs once per space, so it is a good fit for onboarding and a poor fit for anything that repeats.

5. On a schedule: the tickets nobody triggers #

The fifth group is the one teams most often leave manual, because it has no event. Jira Automation handles it with the Scheduled trigger. According to Atlassian's triggers page (September 2026), you can run a flow at a fixed rate, for example every 7 days, or use a cron expression for more complex schedules. Two details from the same page matter for anyone relying on it:

• You can add a JQL query, and then the flow's actions run against the work items the query returns rather than creating something fresh.
• Scheduled flows that reach a Failure status for 10 consecutive executions will disable automatically. A routine ticket can quietly stop appearing, and nobody notices until the report it prompted is missed.

For fixed-rate schedules this works well. It gets harder when the real schedule is "the last working day of the month", "every second Tuesday", or "the first of the quarter unless it falls on a holiday". Our Jira cron expression guide shows how far cron goes and where it stops.

What scheduled automation costs #

Every flow run spends steps from your organisation's monthly allowance. Atlassian's usage page lists these Jira allowances as of September 2026:

The allowance is pooled across your Atlassian apps. On the same page Atlassian says extra usage is billed at $0.50 per 1,000 additional steps, that extra usage billing takes effect on December 3, 2026, and that with extra usage disabled, flows stop running at 100% of the allowance until usage resets. A dozen routine tickets a month is a small draw on its own. The risk is that they share the budget with every event-driven rule you built in sections 1 to 4, so a busy month elsewhere can stop the routine ones. Jira Automation pricing goes through the arithmetic.

A scheduling app for the time-driven tickets #

For the calendar-driven group there is a second way to do it: a Marketplace app built only for recurring tickets. Recurring Work Items for Jira is ours, so weigh this section accordingly. It does one job. You write a rule once in a Jira project, a schedule plus an issue template, and the app creates the ticket each time the schedule comes round.

What it does, as its live documentation describes today:

• Daily, weekly, monthly and quarterly rules, with working-day and holiday handling, so "last working day of the month" is a setting.
• Dynamic titles, so the ticket can read "Access review, October 2026". The token reference lists what you can put in a title.
• Subtask checklists created with the ticket.
• A run history on every rule that records each occurrence as created, skipped or failed, with the reason. A skipped run shows up in the history.
• It consumes no Jira Automation quota. The scheduling is the app's own and never creates or runs an Automation rule, so the time-driven tickets stop competing with your event-driven ones.

Its limits, stated plainly: it is scoped to one project at a time, with no site-wide rules; it is Jira Cloud only, with no Server or Data Center build; and it does nothing about events. It will not create a ticket when a form is submitted or a webhook arrives. Pricing on the site today is free for up to 10 users, then from $82.50 a year for 11 to 15 users.

Which approach fits your team #

Most teams end up with both: Jira Automation for everything that reacts to an event, and something purpose-built for the calendar. For a longer comparison of the calendar options alone, read Jira recurring tasks: Automation, cloning, or a scheduling app?.

When the manual way is enough #

Automating ticket creation is not always worth it. Keep typing the ticket when:

• It happens a few times a year. Building and maintaining a rule for the annual licence renewal costs more attention than writing the ticket.
• The content changes every time. If each ticket needs fresh judgement in its description, a template saves little and a rule saves nothing. A saved issue to clone, as in Jira task template, may be all you need.
• Nobody would notice if it stopped. An automated ticket that fails silently is worse than a manual one somebody remembers. If you automate, pick a tool that tells you when a run did not happen.

How to get started this week #

1. List every ticket your team created by hand last month, with its cause.
2. Mark each as event-driven or time-driven.
3. Build the two or three most frequent event-driven ones in Jira Automation first. They have the clearest payoff.
4. For the time-driven ones, decide between the Scheduled trigger and a scheduling app based on how many there are, how irregular their calendar is, and how much automation allowance you have left.
5. After a month, check the audit log or run history to confirm every expected ticket appeared.

Aim for this: every ticket that happens for a predictable reason stops depending on somebody remembering to type it.