Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Jira ticket cloning

VanshikaG
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
May 19, 2026

I am working as a PMO for a Managed Services team, where the complete operational workflow is handled through Jira Service Management (JSM). Tickets are created, assigned, worked upon, and resolved within the platform.

However, in some cases, tickets remain open for extended periods due to dependencies such as awaiting customer inputs, approvals, third-party responses, or long troubleshooting timelines. From a compliance and operational reporting perspective, we aim to ensure that tickets do not remain open beyond a 7-day window.

To address this, I would like to understand whether Jira ticket cloning can be implemented for tickets that exceed the defined timeline. The objective is to close the original ticket within the compliance window while automatically creating a cloned/linked ticket that carries forward the pending work and context.

I would appreciate guidance on the following:

  • Is this approach recommended in JSM for SLA/compliance management?

  • Can ticket cloning be automated based on ticket age, SLA threshold, or status conditions?

  • Is this achievable through native Jira automation, workflows, or would marketplace apps/plugins be required?

  • How can we maintain traceability between the original and cloned tickets for reporting and audit purposes?

  • Are there any best practices or alternative approaches commonly used for such scenarios?

Looking forward to suggestions and recommendations from the community.

3 answers

2 votes
Aaron Pavez _ServiceRocket_
Community Champion
May 19, 2026

Hi @VanshikaG 

Ill suggest to take a look at ITIL for best practices. Good place to start.

> Is this approach recommended in JSM for SLA/compliance management?

its not for several reasons. reports, customer sentiment (too many tickets), the audit gets confusing (5 tickets opened for the same issue with no resolution and keeps piling)

The cloning part is the not so good/best practice. closing the ticket when the SLA says so , yes.

> Can ticket cloning be automated based on ticket age, SLA threshold, or status conditions?

yes you can. Jira automation is limited on what it can copy/clone. 

https://support.atlassian.com/jira-software-cloud/docs/clone-an-issue/

> Is this achievable through native Jira automation, workflows, or would marketplace apps/plugins be required?

Automation, limited. best use a 3rd party app.

https://community.atlassian.com/forums/App-Central-articles/The-Complete-Guide-to-Cloning-in-JIRA-in-2026-How-to-Clone-Work/ba-p/3013253

> How can we maintain traceability between the original and cloned tickets for reporting and audit purposes?

If you want to go this route, its either a label or a link.

> Are there any best practices or alternative approaches commonly used for such scenarios?

move the ticket to another work type with a longer SLA.

train people to work on the work items and reply accordingly.

chase customers for reply.

Regards

VanshikaG
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
May 20, 2026

Thanks for your inputs. I will explore more around this. 

0 votes
Evelin Bayer - codefortynine
Contributor
June 25, 2026
Hi  @VanshikaG ,
 
Quick note upfront: I work at codefortynine, the vendor behind Deep Clone for Jira.
 
So naturally it's the cloning part of your question that piqued my interest — I'm always keen to understand what people need from advanced cloning and where Jira's built-in capabilities hit their limits.
 
Before diving into cloning, it's worth noting that @Aaron Pavez _ServiceRocket_ raised some valid points in his response about alternatives to cloning that may be worth evaluating.
 
That said, there are scenarios where cloning is a legitimate and practical choice — so let me walk through your questions from a cloning point of view.
 
1. Is this approach recommended in JSM for SLA/compliance management?
 
While Jira Service Management typically encourages keeping a single ticket for its entire lifecycle, your approach is a valid workaround for compliance and reporting when "Time to Resolution" metrics are strictly audited. By closing the original ticket and creating a linked clone, you can "stop the clock" for reporting purposes while maintaining the operational context in the new ticket.
 
2. Can ticket cloning be automated based on ticket age, SLA threshold, or status conditions?
 
Yes, this can be automated. Jira Automation supports scheduled triggers (e.g., a rule that runs daily and checks for tickets older than X days) and SLA breach triggers that fire when a specific SLA metric is about to breach. You can combine these with a clone action.
 
However, Jira's native clone function is very limited — it essentially copies the summary and description, but does not carry over comments, attachments, custom field values, issue links, or subtask structures. For a compliance workflow where the cloned ticket needs the full context of the original, the native clone will leave you with a near-empty ticket that requires significant manual rework.
 
3. Is this achievable through native Jira automation, or are marketplace apps required?
 
As just mentioned: native automation can trigger a clone, but the result is too bare-bones for most real-world compliance use cases.
 
I would recommend using a Marketplace app instead, such as our Deep Clone for Jira app. Deep Clone supports full-depth cloning including comments, attachments, custom fields, issue links, and subtasks. It integrates with Jira Automation, so you can trigger deep clones automatically based on SLA thresholds or scheduled rules. And you can create Cloning Presets to define exactly what gets copied, making the process repeatable and auditable.
 
4. How can we maintain traceability between the original and cloned tickets?
 
When cloning via Jira Automation, you can add the "clones / is cloned by" issue link by adding an action to your automation rule and thus maintain traceability.
 
Our Deep Clone for Jira app handles this regardless of how you trigger the clone — whether manually, via post-function, or through Jira Automation. In addition, it offers more advanced tracing options such as:
  • Automatically adding custom comments to both tickets explaining the reference and providing background information.
  • Prefixing the summary of the new ticket (e.g., "FOLLOW-UP: [Original Summary]") to make it clear in reports.
  • Using dedicated labels.
 
5. Best practices and alternative approaches
 
As mentioned above, cloning is not the only way to handle SLA compliance in JSM — there are other options worth evaluating before committing to a cloning workflow.
 
If you decide that cloning is the right approach for your setup, here are a few tips to keep it clean:
 
  • Use Cloning Presets: In Deep Clone for Jira, you can define presets that ensure every clone — whether triggered manually or via automation — follows the exact same rules (which fields to copy, which status to start in, etc.).
  • Keep the customer in the loop: Use Jira Automation to notify the customer when a new ticket has been created for their request. Transparency here avoids confusion and support overhead.
 
If you have questions about advanced cloning functions using Deep Clone for Jira  - feel free to reach out.
 
Best,
 
Evelin
codefortynine
0 votes
Olga Cheban _TitanApps_
Atlassian Partner
June 4, 2026

hi @VanshikaG !
Welcome to the community!

As Aaron mentioned earlier, the cloning approach has its drawbacks. As you also asked for best practices, here's what I can share.

A common approach is to close tickets automatically after a period of inactivity and then reopen them automatically if the user replies. Before the ticket is closed, the automation rule can add a comment notifying the user that the ticket will be closed unless they provide their input. This can be done with native Automation for Jira.

For a detailed rule scheme and other best practices, you can take a look at my article 10 Jira Service Management Automation Rules That Every Team Should Use.

I hope this helps!

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
TAGS
AUG Leaders

Atlassian Community Events