Blog · 26 September 2026

Bulk clone issues in Jira: what works in Jira Cloud

To bulk clone issues in Jira Cloud, there is no Clone option in the bulk change menu. Cloning is a one-item action from the item's More actions menu. The native way to clone many items at once is a Jira Automation rule: a trigger that finds the items with a JQL query, and a Clone work item action that copies each one, with a branch if you also want their subtasks. The other route is a CSV round trip, which is quicker to set up and copies less. And if the reason you are cloning a batch is that the same batch is due again every month, the better answer is to stop cloning and have the items created on a schedule. This guide covers each, as of September 2026.

Jira now calls issues "work items" and projects "spaces" in much of its interface, so the menu names below use the new words.

The options at a glance #

Why bulk change has no clone #

The bulk change screen in Jira Cloud edits, transitions, moves and deletes the items you select. It does not copy them. Atlassian's page on cloning describes a single item at a time:

To clone a work item: Open a work item. Select ··· > Clone.

That page also sets out what a clone copies. The summary and description always come across, and "some information from the original work item isn't automatically cloned but can be included: Attachments Subtasks Links Custom fields (if they're set up to be cloned) Comments Child work items (for Epics)". You need the Create work items permission in the space. And one detail every bulk cloner meets: "the prefix Clone is automatically added to the Summary of a cloned work item."

So a bulk clone in Jira Cloud is always one of two things: a rule that clones each item in turn, or an export and re-import that creates new items from copied values.

1. Clone one at a time (when the batch is small) #

For five or six items this is still the fastest honest answer:

1. Open the first item.
2. Select More actions (•••), then Clone.
3. Tick the extras you want: attachments, subtasks, links, comments, child items for an epic.
4. Pick the target space if it differs, then Clone.
5. Edit the Clone prefix out of the summary.

It needs no setup and no admin, and it carries the most, because you choose the extras per item. It stops being sensible somewhere past ten, when the repetition and the prefix clean-up start costing more than a rule would.

2. Bulk clone with Jira Automation #

This is the native bulk clone. A Jira Automation rule finds the items and clones each one.

The rule, step by step #

1. Pick a trigger that can find a set. The Scheduled trigger accepts a JQL query. Atlassian's trigger reference says of it: "This flow runs on a specified schedule." and "You can also choose to enter a JQL query." Every item the query returns goes through the actions below.
2. Write the JQL for the batch, for example project = OPS AND labels = q3-template. Test it in issue search first, so you know the count before anything is created.
3. Add the Clone work item action. Choose the target space and work type, and set the summary so the Clone prefix never appears. A smart value such as {{issue.summary}} copies the original summary unchanged.
4. Add a subtask branch if you need the children. Atlassian's own knowledge base article on cloning a task with its subtasks does it in three moves: clone the parent, store the new key in a variable, then branch over the subtasks and clone each with that variable as its parent.
5. Run it once and check the output, then disable the rule if the batch was a one-off.

The variable in step 4 is the part people miss. Atlassian's article explains why it is needed:

Without a variable to store the first parent issue's cloned key, subsequent cloned subtasks will change the value of smartvalue {{createdIssue.key}} during the execution.

The manual trigger does not do bulk #

The Manual trigger from work item looks like the right tool, because you run it on demand. It runs on one item. Atlassian's reference says "anyone with access will be able to trigger it by going to a work item and selecting Actions". That makes it handy for cloning one item with its subtasks in one click, and no help for fifty items at once.

What to watch #

• Rule runs count against your plan's automation allowance, and a large clone can be a large number of actions. We covered how usage is counted in Jira Automation pricing and the ceilings in Jira Cloud automation limits.
• A scheduled rule that keeps failing switches itself off. The same trigger reference says "Scheduled flows that reach a Failure status for 10 consecutive executions will disable automatically."
• The clone copies the original as it is now. If somebody edited the source items since you last looked, the batch inherits those edits.

3. The CSV round trip #

When you need the field values in another space and do not care about history, a spreadsheet is quick:

1. Run the JQL for your batch in issue search.
2. Export the results to CSV with the columns you want copied.
3. Delete the key column, or the admin importer may read it as an update to the original rather than a new item.
4. Change the space column, or pick the target space on import.
5. Import the file. Our Jira bulk create guide walks through both importers and their batch sizes.

Treat this as copying values, not cloning items. An import builds each new item from its row. Anything that is not a plain column value, such as comments, attachments and links to other items, needs extra work or does not come across. The quick importer that space admins can use also cannot build a parent and child hierarchy, so subtasks need the admin importer.

4. Stop cloning: when the batch repeats #

A lot of bulk cloning is the same job every cycle. The month-end checklist, the quarterly access review, the sprint's standing chores: somebody keeps a set of "template" items and clones them into the new period. It works, and it has three weak spots:

• The template is an ordinary item. Somebody edits it, closes it, or moves it, and the next clone inherits the mistake.
• A person has to remember. The batch exists only when somebody runs the clone.
• Every copy needs its date fixed. The clone carries last cycle's due date and title.

If you clone the same set on a calendar, what you actually want is a schedule. In Recurring Work Items for Jira, a rule is the template: it stores the item type, summary, description, due date, assignee, reporter, priority, labels, custom fields and an ordered list of subtasks, and creates the item on the pattern you pick. The text fields take tokens, so a monthly rule produces "Access review: September 2026" with a due date a few working days out, instead of last month's title with a Clone prefix. The token vocabulary is on the tokens page, and the editor shows the next runs before you save. The app is turned on per space, so one team's rules never land on another team's board.

For the wider comparison of scheduling approaches, see Jira recurring tasks, and for building the reusable structure itself, Jira task template.

When the manual way is enough #

Plenty of bulk clones should stay bulk clones:

• A one-off copy into a new space, such as seeding a new team's board from an old one. Use an Automation rule or a CSV, then delete the rule.
• A small batch, now and then. Clone by hand. It carries the most and needs nothing set up.
• A whole epic tree with linked items, copied once. The item-level Clone with child items ticked, or a template app, fits that better than a schedule, which creates one item with its subtasks rather than a multi-level tree.
• The set changes every time. A schedule is for work that repeats. If each batch is different, a JQL-driven clone rule is the right tool.

Which to choose #

The question that decides it is whether you will clone this batch again. If not, clone it and move on. If yes, the clone is a schedule you are running by hand.