Automation of Story and Sub Task creation

[Dan Allenby]

I have a Kanban board set up for all my customer onboardings, which is linked to a Jira Service Management (JSM) board. Currently, when a service request is raised, an automation rule triggers the creation of an Epic on my Kanban board.

What I want to achieve next is:

• Once the Epic is created, I want Stories and Sub-Tasks to be automatically generated under it.

• Each Story represents a phase of onboarding (e.g., Readiness, Security).

• Each Sub-Task represents specific tasks within that phase (e.g., Setup meeting, Configure security).

• The set of Stories and Sub-Tasks should depend on the package the customer selects.

Example workflow:

1. Customer raises a ticket (Service Request).

2. Automation creates an Epic.

3. Based on the Package selected (e.g., Package 1):

   • Create Stories: Readiness, Security, etc.

   • Under each Story, create Sub-Tasks: Setup meeting, Setup security, etc.

Question:
How can I automate Jira so that once a user logs a ticket, all relevant Stories and Sub-Tasks are automatically created under the Epic, according to the package selected?

[Alexander Nilsson]

Hello Dan, 

thanks for your question. 

This idea is possible with Jira Automation by using two rules: one in JSM to create the Epic (which you already have) and a second one in your Software project that generates the Stories and Sub‑tasks based on the selected package. Atlassian’s own examples for creating multiple Stories and Sub‑tasks from an Epic follow the same pattern.

How to set it up

• Rule 1 (JSM → Epic): Service request is created → action “Create issue” (Epic) in your Kanban project, and copy the “Package” field to the Epic so the next rule can read it. The general “create work item and subtask” and automation actions docs show how to configure the create‑issue action and field mapping.
• Rule 2 (Epic → children): Trigger “Issue created” → condition Issue type = Epic → IF/ELSE branches on Package value (Package 1, Package 2, …). In each branch use multiple “Create issue” actions:
  
  • Create Stories with Parent = {{issue.key}} (the Epic), as shown in the KB for creating multiple Stories on an Epic.
  • Immediately after a Story is created, store {{createdIssue.key}} in a variable and use that variable as the Parent when creating multiple Sub‑tasks, following the pattern in “Create new stories/tasks and respective subtasks when the automation rule is triggered”.

For step‑by‑step guidance, these official docs are very close to your use case:

• Create new stories/tasks and respective subtasks when the automation rule is triggered
• Jira smart values – issues (for {{issue.key}} / {{createdIssue.key}})

Hope that helps and feel free to reach out if you have any follow-up-questions. 

Greetings, 

Alex

[Dorota Popowska - Vilisoft]

Hi @Dan Allenby 

This is a great use case, and it’s actually very similar to the scenario described in this Community article about building reusable task structures with Jira’s native features: https://community.atlassian.com/forums/App-Central-articles/Why-repetitive-work-deserves-better-than-manual-effort/ba/p/3145891 .

The idea is to create a template hierarchy using normal Jira issues: an Epic with all the Stories you typically need, and each Story with its usual Sub-Tasks. This hierarchy becomes your reusable onboarding structure.

When you use Clone Expert for Jira, you can clone this entire hierarchy whenever a new customer request comes in. During the cloning step, you can customize the work items in the preview table by adjusting titles, removing tasks that don’t apply to the selected package, and adding any package-specific details for that client. It gives you a consistent structure without forcing automation to manage every branching scenario.

And if your process requires adding tasks to an existing Epic (for example, one created automatically by Automation or manually by someone else), Clone Expert supports that as well. You can clone only the child work items from your template and attach them to the existing Epic, without cloning the Epic itself. You can tailor the cloning method to whatever workflow works best for you.

Two upcoming features will also help in onboarding scenarios:
• Auto-date adjustment for shifting timelines automatically.
• On-clone placeholders, letting you inject client-specific details during cloning.
Both are planned for early January.

If you’d like to see how this works end-to-end, we’d be happy to show you a live demo (book my time here) and help design the most effective task structure for your onboarding process.

In the meantime, see the documentation and short video.

Bye!

Dorota

[Olga Cheban _TitanApps_]

Hi @Dan Allenby !

There's also a more straightforward way to achieve this. You can save your standard set of onboarding tasks as a reusable template - and then set up one Jira Automation rule that will create a full set of tasks from that template. (You will need to create separate rules for separate templates, though).

Here's an example of such a template created with our solution, Smart Templates for Jira. In this case, it's an epic with tasks and checklists (they are collapsed), but a template can also include subtasks or any custom hierarchy levels you have.

Why this is convenient - you can manage templates more easily and with more transparency because they are not hidden "inside" an automation rule. 

Also, smart templates support variables, such as {{name}}. This makes it easy to adjust one template for multiple uses. They also work well with smart checklists - for example, you can add a client onboarding checklist to your standard set of onboarding work items. Here's an example:



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