Clone EPIC & Stories to New Epic and link New Stories via Automation

[Sandeep Kumar]

am working on company managed project, tried all ones mentioned still no luck. https://community.atlassian.com/forums/Jira-questions/Clone-EPIC-amp-Stories-to-New-Epic-and-link-New-Stories-via/qaq-p/2257134#U3230263

@Corey Wicks 

While cloning epic and stories, stories are getting swapped when new cloned epic is created or under old epic new stories are getting cloned. Looking forward for your insights.

[Trudy Claspill]

Hello @Sandeep Kumar 

The problem is your Edit action within the For Stories branch. That is being executed against the source issue, not the issue created by the Clone action.

Rather than using the separate Edit action you need to set the Epic Link field (or the Parent field) within the Clone action.

Can you also show us the details of your Create Variable action?

Let us know if you have additional questions about that.

[Trudy Claspill]

Hello @Sandeep Kumar 

Please show us the details on the Clone Issue action and the details of your Create Variable action.

[Ivan Manolov _Appfire_]

Hi @Sandeep Kumar,

Building on @Trudy Claspill's point: the failure mode is exactly what she described — the Edit action inside the branch runs against the source (the original story), not the cloned copy. The fix is to set the parent inside the Clone work item action itself, so the new story is born with the right parent. Here's a rule structure that works.

Rule structure:

1. Trigger: Manual trigger (or whatever trigger you prefer - manual is easiest to test).
2. Action: Clone work item (this clones the Epic itself).
   • Set the destination project, work type Epic, summary {{triggerIssue.summary}} - Copy, etc.
3. Create variable: newEpicKey = {{createdIssue.key}}
   • This captures the cloned Epic's key before the next branch runs, because {{createdIssue}} gets overwritten by every subsequent Clone action.
4. Branch: For each related work item → JQL parent = {{triggerIssue.key}}
   • This iterates over the original Epic's stories.
5. Inside the branch — Action: Clone work item (this clones each story).
   • In the Clone action's field overrides, set:
     • Parent = {{newEpicKey}} (this is the critical bit Trudy was pointing at)
     • Summary = {{issue.summary}} (the iterator {{issue}} here is the current source story)
     • Project = same destination as the new Epic
   • Do not add a separate Edit action after the clone — that's what was rewriting the wrong issue.

A couple of things that bite people on this rule:

• Use the Parent field, not Epic Link. Atlassian retired Epic Link in favor of Parent for story-to-epic linking on company-managed projects. If your project still shows Epic Link as a configurable field, set both to be safe.
• Capture newEpicKey in step 3, not later. If you reference {{createdIssue.key}} inside the branch, every cloned story will have already overwritten it, and the value points to the most recent clone (whichever story finished last).
• Branch ordering isn't guaranteed. If story order matters (e.g., Story 1 should reference Story 2 via a link), the For each branch may execute in any order. For ordered work, switch to a Lookup work items action with explicit ordering and iterate manually.
• Sub-tasks. If your stories have sub-tasks too, the Clone action has a checkbox Include sub-tasks, which clones them under the cloned story automatically. That's the easiest way to handle three-level structures.

Hope this helps,

Ivan

[Ivan Manolov _Appfire_]

@Sandeep KumarOne more thing worth mentioning, in case the rule keeps fighting you on edge cases.

If you're open to solutions from the Atlassian Marketplace, JXL is a spreadsheet-style view for Jira that handles this kind of bulk duplication without automation. You'd open a sheet showing the source Epic with all its children expanded, select the rows you want to copy, paste them under the new Epic, and JXL creates the new stories with the correct parent set in one step. Useful when you do this every sprint or release and don't want to maintain a brittle rule.

Disclosure: I work for the team that builds JXL.

Cheers,

Ivan

[Olga Cheban _TitanApps_]

hi @Sandeep Kumar !

Cloning an epic with its child stories through Jira Automation can be tricky, indeed. As Trudy mentioned, the Edit action in your "For Stories" branch targets the source issue, not the cloned one - and that's where the parent link goes wrong.

If you need to create copies of the same epic often, there's a simpler way. Our solution Smart Templates for Jira lets you save an entire set of work items as a reusable template.  In your case, this template can consist of your epic with all its stories. Once you saved it, you can generate the entire set of work items from this template with one push of a button.

Here's an example of a template with similar structure:

When you apply the template, all work items are created with the correct parent-child links already in place. There are no clone actions, and no stories ending up under the wrong epic.

You can also pre-fill fields like assignee, priority, and components for each work item. So every new set of tasks comes out exactly the way you need it. You can also add variables for fields that change each time, like client name or sprint. This keeps the structure consistent and lets you adapt one template for multiple uses.

The setup is simple and intuitive - you build your template in the app's UI, not in the automation engine. It works well in company-managed projects and doesn't require advanced Jira admin knowledge.

Let me know if you have any questions!

[Sandeep Kumar]

Could you please share all the detailed steps @Trudy Claspill ?