Advanced Cloning Options

In the following sections, you’ll discover advanced cloning options that streamline your workflow and help you create ready-to-use work items.

🧩Cross-project clone

Clone Expert allows you to clone any Jira issue including entire hierarchies into a different project than the one it originally belongs to.

This is especially useful when copying reusable task structures, templates, or work items between teams, departments, or business units.

In the cloning form, you can define both the destination project and the cloning strategy to determine how issue types will be mapped and where each linked item will be created.

✅ When to use it

Use cross-project cloning when you need to:

  • Copy an issue or hierarchy to a different Jira project
  • Reuse templates or recurring workflows across teams
  • Support shared processes across departments (e.g. HR → Legal, Product → Marketing)
  • Preserve multi-project hierarchies – for example, when an Epic contains child issues from different projects and you want to retain this structure in the clone

🛠️ How it works

While in the cloning form, go to the Destination project field and select your target project (default: the same project as the source issue).

Option for destination project selection

Next, choose one of the two available Cloning Strategy options – this determines where linked child issues will be created:

🔹 Child work items cloned to the project where they already exist

Select this strategy if you want to maintain original project distribution – child issues will be created in the same projects they currently belong to.
For example, if an Epic includes child issues from multiple projects, each will be cloned into its original project.

Even if you change the Destination project, the Epic will be created in the new target project, while the child issues will be recreated in their original projects.

 Child work items cloned to the project where they already exist

🔹 Child work items cloned to Destination project

Choose this strategy if you want all linked issues, including child items, to be cloned into the same target project selected in Destination project – ideal for consolidating structures in one place.

Child work items cloned to Destination project

💡 Tips

  • Use “Child work items cloned to the project where they already exist” if you want to preserve the current cross-project structure – perfect for distributed teams or multi-team epics
  • Use “Child work items cloned to Destination project” if you want to consolidate the entire hierarchy into a single project – ideal for templates, planning, or standardizing work
  • You can switch strategies at any time in the cloning form – the preview table will reflect the change immediately

🧩Attachment clone

If you want to include attachments in the cloning process, enable the checkbox “Attachments” in the Include section of the cloning form.

When checked, attachments from the selected work item or hierarchy will be cloned into the new issues.

This option is not selected by default, and it is only visible when the selected issue(s) actually contain attachments.

💡 Tips

  • Attachments are cloned as part of each issue individually, including child issues and subtasks
  • If the “Attachments” checkbox is missing, it means no attachments are present in the selected items
  • Useful when duplicating documents, specifications, or visual assets that are critical for the task

🧩Copy comments

To include comments in the clone, enable the checkbox “Comments” in the Include section of the cloning form.

When selected, all existing comments will be copied to the cloned issue.

This option is not selected by default and will only appear if the selected issue(s) contain at least one comment.

💡 Tips

  • Comments are copied per issue, including child issues and sub-tasks
  • The author of the cloned comments will always be the person performing the clone
  • The timestamp of each comment reflects the moment of cloning, not the original comment date
  • Jira does not allow setting historical authors or dates for comments
  • This feature is useful to preserve the collaboration context, especially for recent decisions or discussions
  • If no comments are found, the “Comments” option will not appear in the cloning form

Both options are disabled by default and will only appear if the selected issue(s) contain at least one issue link or watcher.

💡 Tips

  • Issue links preserve relationships with connected work items – such as “relates to”, “blocks”, or “duplicates”
  • Linked issues are not cloned, only the connections are recreated
  • Watchers are copied as-is from the original issue, helping maintain visibility for key stakeholders
  • Jira permissions apply – only watchers who have access to the destination project will remain valid
  • If no links or watchers exist in the selected issues, the options will not be displayed
  • Useful when maintaining continuity across related issues, especially in cross-team collaboration

By default, the link type is set to “clones”. If this option is not available in your Jira instance, the first available link type from your system configuration will be selected automatically.

💡 Tips

  • The link is created between the original issue and the top-level cloned item
  • You can choose any link type configured in your Jira instance – e.g. “relates to”, “blocks”, “causes”, etc.
  • The dropdown dynamically reflects your system’s available issue link types
  • This feature is useful for audit trails, traceability, or post-cloning review workflows
  • Linking is optional and does not affect the content or structure of the cloned issue
  • Ideal for internal collaboration – e.g., creating internal development or design tasks based on tickets received via Jira Service Management