d2237e6804e2 - thanks for this, helpful. I have one issue that you can maybe help with. When I set the for:children part, the outcome is that the child issues are copied under the original Epic and not the new copied one. Is this something you could help with? I am probably just doing something wrong here, thx!
M.

For Repeatable work, our teams are responsible for both operational support and new development.  On the operational side, we typically create the same epic, story, sub-task set for each quarter (we do qtrly PI-planning).  Today teams either manually create the set of issues, manually clone existing issues, or manually trigger automation to create the issues to keep the work visible and reminders to do the repeatable work each quarter/sprints.

We haven't implemented yet but have talked about creating a repository of standard requirements that must be evaluated and those that need to be worked in a new project created/cloned/copied into another project.

Hey all, would love to know more about the use cases you have for this, and what problem is to be solved here. 

We are considering something along the lines of repeatable tasks (this has not started, but is being considered), and I'd love to learn more to understand if the needs here are similar to what we are trying to solve.

Cheers!

Liron

Group Product Manager, Jira 

1a3ef95aaaa8 can you reach out to me and show my your hacky? (Im willing to compensate) cassie.goss@yoursolutionarchitect.com 
I am struggling doing this and paying for an addon is not an option right now.

I found a hacky workaround to also include a limited amount of sub-tasks per task for cloning epics for anyone interested and the new userInput feature is great for that as that will be the name of the new epic.

You can use the list issue.subtasks to get to the respective sub-task but will have to use some variables to store the needed issue keys.

In the for-loop to create the epic's children you have to
1. save the issuekey of the created task as a variable from createdIssue.key

2. create the sub-task by using the respective sub-task using the get() function (e.g. create the 1st subtask by setting the values of e.g. summary to issue.subtasks.get(0).summary

3. create the nth,... subtasks by checking the number of subtasks issue.subtasks.size  > n+1

4. if another subtask is found via this condition you can create the next sub-task by using e.g. {{{}issue.subtasks.get(1).summary

{}}}This will support sub-tasks for "simple fields" you can reach via the get() function.
For instance, I dont think it would be possible to support attachments doing this.

As this is not a loop it will support as many subtasks as have been manually built into the rule. I'm currently supporting up to 10 sub-tasks, including an error message if {{issue.subtasks.size }}> 10 as a comment to inform the user of missing sub-tasks

Would love to see this feature as well, seems like pretty basic functionality

The new prompt functionality is great to get the name for the next epic!

Do you also have a trick up your sleeve to include the sub-tasks of the tasks that are part of an epic, Tom?
Unfortunately, you cant have another for loop inside the for loop and eventually it gets a bit tricky finding the right smart values to get the data from the correct issues :/

Hi @3ecaf3928967, 

This automation can be configured at the site level, as a global automation, requiring only 1 configuration per site.

Atlassian are developing many things at once, but they cannot complete every feature request immediately. Would you rather continue your manual and time consuming method while waiting for Atlassian, or take 10 minutes to leverage the tools already provided and solve your problem?

Automation for Jira is a powerful tool which we can use to extend the functionality of Jira, without relying on Atlassian's (sometimes painfully slow) development cycle.

@Tom Gionfriddo, why shall thousands of users setup a complex automation if Atlassian can create this as a feature?

This functionality can be easily achieved using Automation for Jira. You could utilise the prompt for input when this rule is triggered option in the trigger to make make this more complex, potentially re-writing issue summaries etc.

• Trigger: Manual Trigger
  • If: Issue Type = Epic
  • Then: Clone issue into same project
  • For: Children
    • Then: Clone issue into same project