How to duplicate a Jira issue

To duplicate a Jira issue, open it, use the more-actions menu (the ...), and choose Clone — Jira creates a copy, adds “CLONE -” to the summary, and links the two issues together. By default that copy carries only the summary and description: sub-tasks, attachments, issue links, comments, and (for epics) the child issues underneath are all optional checkboxes in the Clone dialog, not automatic, and some custom fields won’t come across no matter what you tick. That’s the right tool for a genuine one-off copy. If “duplicate this issue” really means “I make this same kind of issue every week,” cloning turns into a manual ritual — re-ticking the same boxes and fixing the same gaps — and what you actually want is a reusable issue template.

The native way: Clone

Open an issue, open the more-actions menu (the ...), and choose Clone. Jira creates the copy, prefixes its summary with “CLONE -”, and automatically links the two issues together. That’s the whole feature, and for copying a single existing issue right now it does the job.

What to watch for:

• Only the summary and description come across by default. Everything else — sub-tasks, issue links, attachments, comments, and (for epics) the child issues underneath — is an opt-in checkbox in the Clone dialog. Leave one unticked and that piece simply isn’t on the copy.
• Some custom fields don’t clone at all, depending on how they’re configured, regardless of which boxes you tick. Always diff the clone against the original before you trust it.
• It’s a copy of one issue, not a blueprint. You’re duplicating whatever state that specific issue happens to be in right now — including stale values you didn’t mean to carry over.
• There’s nothing reusable behind it. Clone doesn’t create a saved template. Next week you find the “good” issue again, clone it again, re-tick the same checkboxes, and fix up the same gaps again.

For a true one-off, that’s all fine. The moment the same duplication is recurring, cloning turns into a manual ritual.

(Note on terminology: Jira’s UI has been rolling out “work item” as the replacement for “issue” — same feature, new name. “Issue” is still how most people search and talk about it, so that’s what this guide uses.)

When you’re really making a template

If you create the same shape of work over and over — an onboarding checklist, a release plan, a standard bug write-up, a full epic → story → sub-task breakdown — what you actually want isn’t a copy of one issue, it’s a reusable definition. Jira has no native “issue template” feature, so this is where teams reach for a templates app.

Prefab lets you define an issue (or a whole epic → story → sub-task tree) once, then create a fresh, consistent copy from it on demand — with the fields you want pre-filled and nothing stale carried over.

Why that beats cloning for recurring work:

• Define once, reuse forever — the structure lives as a template, not inside one aging issue you have to go hunting for.
• Consistent every time — new issues start from the intended fields and hierarchy, so you’re not fixing up the same gaps on every clone.
• Whole trees, not just one issue — spin up the entire epic → story → sub-task breakdown in one go, instead of cloning pieces and re-linking them.

The full picture of pre-filling and standardising issues — from description defaults to full template trees — is in how to create issue templates in Jira.

Which should you use?

• Copying one existing issue, once? Use Clone — tick the boxes for sub-tasks, links, and attachments you need, and check that custom fields came across.
• Making the same kind of issue (or the same epic → story → sub-task tree) repeatedly? That’s a template, not a clone — define it once with a templates app like Prefab so every new issue starts consistent.