For some of our IT Operations teams we have recurring tasks that need to be done every week or month. Just using the Automation - "Set To Recur" feature will allow me to create another ticket exactly the same as the original, but there's a few more steps I'd like to happen that I'm not sure how to achieve * Add the new ticket to the same parent Epic as the original * Populate the Due Date to be 7 days after the ticket is created * Append the Due Date to the ticket subject, so there's an obvious difference * Add the new ticket to the current active Sprint Anyone done this that can share a few pointers? I was thinking that if I add a label of "Recurring" to the original ticket then I can use that to help target any automations on just the tickets that need it. This is currently a Team Managed Project if that makes a difference, but will be moving to a Company Managed in due course Thanks

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to add recurring ticket to the correct Sprint and Epic?

Alex Cook_ms1l72

For some of our IT Operations teams we have recurring tasks that need to be done every week or month.

Just using the Automation - "Set To Recur" feature will allow me to create another ticket exactly the same as the original, but there's a few more steps I'd like to happen that I'm not sure how to achieve

Add the new ticket to the same parent Epic as the original
Populate the Due Date to be 7 days after the ticket is created
Append the Due Date to the ticket subject, so there's an obvious difference
Add the new ticket to the current active Sprint

Anyone done this that can share a few pointers?

I was thinking that if I add a label of "Recurring" to the original ticket then I can use that to help target any automations on just the tickets that need it.

This is currently a Team Managed Project if that makes a difference, but will be moving to a Company Managed in due course

Thanks

Accepted answers

All comments

Duc Thang TRAN

Hello @Alex Cook

For the trigger scope, for me it’s better to use the issue key since there is only one ticket.
If you have several tickets to duplicate, using a label is not a bad choice.

On the clone action:

1 - You can use field parent = copy it from the trigger issue

2 - You can use a smart value for the Due Date like this:
{{now.plusDays(7)}} -> https://support.atlassian.com/cloud-automation/docs/jira-smart-values-date-and-time/

3 - In the summary, you can add something like:
{{issue.summary}} - {{now.plusDays(7).format("dd/MM/yyyy")}}

For the active sprint, I’m not sure if your ticket model has only one sprint value (which would be the active sprint). In that case, you can simply copy the value from trigger

if the ticket model contains several sprint values including one active sprint,

-> I think you can use this smart value {{#issue.Sprint}}
{{#if(equals(state,"active"))}}{{id}}{{/}}
{{/issue.Sprint}}
more information about list : https://support.atlassian.com/cloud-automation/docs/jira-smart-values-lists/

Hope this can help

Alex Cook_ms1l72

Thanks. I'll give that a go on Monday, and yes we will have several tickets to duplicate in each project as there's maintenance work on multiple systems that will be done by different people, hence the thought of using a label

Luka Hummel - codefortynine

Hi @Alex Cook and welcome to the community!

You can get pretty close with native Set to recur + Automation smart values (and the existing answer already points you in the right direction for summary and active sprint smart values).

If you want this to be reliable and low-maintenance (especially once you move to a company-managed project), the cleanest pattern we see customers use is: keep a single “template” work item, then generate the next occurrence by cloning it with Deep Clone for Jira and doing the “dynamic bits” (due date / summary / sprint) via its Field Editor feature and Jira Expressions in a predictable step.

Why Deep Clone for Jira helps here

Epic/parent relationship: Your clone can retain the original’s hierarchy/parenting setup (so the new work item lands in the same Epic context without you manually re-linking it).
Field control: You decide exactly which fields are cloned and which are set/overwritten (useful for recurring operational tickets).

Once you’re on company-managed, you can use the workflow approach with a Jira Automation (looping transition + Deep Clone post function), which is typically the most robust for recurring operational processes.

Alex Cook_ms1l72

Thanks, that sounds like it's worth exploring.

I *did* get an automation set up that looks for any new ticket with a label of "Recurring" then makes the amends and it worked as intended on one of the Projects.

When I created exactly the same thing on a different project it only triggered if I manually cloned a ticket rather than when it auto-recurs so something isn't quite right.

I've not had time to try and troubleshoot yet though.

Olga Cheban _TitanApps_

hi, @Alex Cook ! I looked into your requirements, and I think I can suggest a viable option. Although it's not a 100% fit, but maybe this information will be useful to you.

I would say the most straightforward way to handle this case would be the following:

1) Use a dedicated app to create Jira issue templates, such as our solution Smart Templates for Jira. You can create standard tickets for recurring tasks and save them as reusable templates.

Then, you will be able to generate new work items from those templates automatically. All the information from the templates will be preserved in new tickets - pre-filled fields, descriptions, and even child work items of any level.

2) Use Smart Templates' native Scheduler. This allows you to easily generate new work items according to your preferences - without setting up Automation for Jira rules.

In this example, the auto-creating is scheduled for every two weeks, but this can be any custom schedule you need.

Smart Templates - Schedule.png

3) For dynamic deadlines, use smart variables. In your case, this will be {{now.plusDays(7)}}. Include them in the ticket summary and wherever else you need to see the deadline. Here's an example:

Screenshot 2024-08-19 at 12.19.50.png

4) Set up a native Jira Automation rule to add the new ticket to the current active Sprint.

In this case, you will only have one simple automation rule. Scheduled auto-generation will be handled by Smart Templates. As an added bonus - it won't cosume your Automation for Jira limits.

What's also convenient is that in Smart Templates, you will have a dedicated History tab listing all the templates you have. From there, it's easy to make updates and manage your templates. You will also see the list of all work items created from a specific template and their statuses.

The visibility here is much better than when everything is hidden "under the hood" in different automation rules.

Smart Templates work for Jira issues of any complexity: your template can consist of a stand-alone task, or it can be an epic with a whole set of tasks, subtasks, and checklists.

I hope this helps! Let me know if you have any questions