Every month, a Jira admin somewhere rebuilds the same epic by hand — copying tickets one at a time, re-adding sub-tasks, then double-checking nothing broke in the process. That’s the shape of most jira recurring tasks: client onboarding, release checklists, quarterly audits, all recreated manually on repeat. Epic Clone now removes that step. Two new actions sit directly inside the Jira Automation rule builder, letting you clone a full epic hierarchy — or the results of a JQL search — on a schedule, a trigger, or an event, with nothing to build or maintain outside Jira.
Why Recurring Tasks in Jira Take Longer Than They Should
Jira’s own “make item recurring” option covers exactly one case well: a single issue, repeated on a schedule. The moment the work is bigger than one ticket — an epic with a dozen stories and links among them, a release checklist with sub-tasks, a project template with a defined structure — that option runs out.
What’s left is a manual rebuild. Someone opens last quarter’s epic, copies it issue by issue, reassigns owners, recreates relationships and hopes nothing gets missed along the way. Sub-tasks get forgotten. Labels drift. Embedded images aren’t cloned. Two copies of the “same” process end up looking different by the third or fourth cycle, and nobody notices until a status report doesn’t add up.
What Changed: Epic Clone Actions in the Rule Builder
Until now, closing that gap meant reaching outside Jira Automation entirely. Epic Clone’s REST API let you trigger a clone from a script, a scheduler, or another system — useful, but it meant building and maintaining a Jira automation rule that sends a web request, with an API token to manage and a payload to get right.
That’s still the correct route for jira cloud automation that has to reach outside Jira — a CRM marking a deal “Won,” a webhook from an external system. But for the common case of cloning work on a schedule or in response to something happening inside Jira itself, it’s more setup than the job needs.
Epic Clone’s two new actions remove that layer. They sit in the standard action library next to Jira’s own steps, so any jira automation rule can clone an item with all its children, or clone the results of a JQL search, without a separate API call to configure.
Cloning an Epic and Its Child Issues from a Rule
The first action, Clone Item with All Children, is the one most jira clone epic and issues requests come down to. Point it at a source issue and it reproduces the full hierarchy beneath it — not just direct children, but sub-tasks, and any further nesting your Jira configuration allows. Parent-child relationships are preserved in the copy, and all important fields carry over: assignee, labels, components, fix versions, or others.
The second action, Clone JQL Results, covers the cases that don’t sit under one clean parent: a set of issues tagged with a particular label in a template project, for instance, rather than a single epic. It’s a smaller piece of this release, but worth knowing it’s there if your recurring work doesn’t fit a strict hierarchy — the Automation actions documentation covers its setup in detail.
Either way, the result is the same kind of Jira bulk cloning Epic Clone has always done — it’s just triggered from inside a rule now, instead of a manual click. For anyone who searched their way here looking to duplicate epic in Jira automatically rather than clone it by hand once, this is that answer: set the rule up once, and every future Jira issue clone automatically runs on its own from then on.
Setting Up a Scheduled Rule Step by Step
Building a rule around either action follows Jira Automation’s usual pattern:
Go to Jira Automation in your project or global settings.
Create a new rule and choose a trigger — Scheduled, if you want the clone to run on a fixed interval, or an issue event if it should fire in response to something happening in Jira.
Add a new action and search the action library for the Epic Clone actions.
Select Clone Item with All Children or Clone JQL Results, depending on whether you’re cloning a hierarchy or a query result.
Configure the action: source issue or JQL query, destination project, and which fields to carry over, clear, or overwrite.
Save and enable the rule.
Once the rule is enabled, every scheduled trigger runs the clone automatically — no one has to remember to kick it off manually. This is the jira recurring tasks automation piece most teams start with, since a scheduled trigger alone covers the majority of recurring-clone use cases. Full configuration options, including field mapping and advanced settings, are covered in the Automation actions documentation.
Four Recurring Setups Worth Automating
These are four of the most common recurring projects in Jira teams automate with the new actions — none of them need anything beyond a rule and a trigger.
Monthly client onboarding. Build the onboarding epic once, with every task your team runs through for a new client, then clone it on a scheduled trigger or when a new client record lands in your CRM. Nothing gets skipped because someone was rushing.
Quarterly compliance audits. Teams that repeat the same checklist every quarter can clone the relevant issues automatically at the start of the cycle, using Clone JQL Results to pull in exactly the ticket set an audit needs — ready to be worked through again without rebuilding it from memory.
Release checklists. A release epic with its usual pre-launch and post-launch tasks can be cloned into a fresh copy every time a new release cycle starts, keeping the checklist consistent release over release.
Employee onboarding. HR or IT onboarding structures — the same epic and tasks for every new hire — can be cloned automatically off a trigger from an HR system or a scheduled interval, instead of a project manager recreating it by hand each time someone joins.
Availability, Permissions, and What Runs Where
For Jira cloud recurring tasks specifically, both actions are available in the automation rule builder for Epic Clone on Jira Cloud. Using them requires the Epic Clone app installed in the instance and Jira Automation available on your plan; the rule itself runs under the permissions of whoever owns it, so that person needs access to both the source and destination projects.
Worth calling out for anyone whose approval this needs: Epic Clone runs on Atlassian Forge, so cloning triggered by these actions stays inside the Jira instance — there’s no outbound web request or API token involved, which was the part of the old REST API approach that needed a security review. That matters more here than on most other pages, since it’s precisely the step these actions remove.
Getting Started
If recurring epics, release checklists, or repeating task sets are part of how your team works in Jira, cloning them by hand every cycle is the wrong use of anyone’s time. Epic Clone’s two Automation actions handle it from inside the automation rule builder you already use — no new API to learn, no clone work tree to rebuild by hand.
Try Epic Clone for free or book a demo to see the automation actions set up on your own instance.