Jira epic template with stories and sub-tasks: the same breakdown every time

A release, a client onboarding or a quarterly audit breaks down the same way each time. Here is how to make a new Jira Cloud epic start with its stories and their sub-tasks already in place, with Jira alone and with an app.

By Rolf Eriksen Published 21 October 2026 15 min read

Checked against Atlassian’s pages on 21 October 2026 · We make an app for this (disclosure)

This page is about the work items under an epic. For the text of the epic itself (goal, problem, scope and how you will know it worked), use our free Jira epic template.

Jira Cloud has no epic template that carries stories and sub-tasks. The native way to get them is an Automation rule: when an epic of a given kind is created, the rule creates the stories under it, keeps each new story’s key in a variable, and creates that story’s sub-tasks under it. It works, with three costs:

• Steps. Every trigger, condition and action that runs is an Automation step. One epic with six children and thirteen sub-tasks comes to an estimated 31 steps.
• Upkeep. The list lives inside the rule, one action per work item, and only admins can edit it.
• No choice. The rule decides from what it can see, such as a label. Nobody picks “the short release” this time.

Cloning a reference epic is the other native route, with its own gaps. If you want people to pick from several epic templates, each with its own stories and sub-tasks, an app such as ours does that. The three child lists on this page work with any of these.

A note on words: Atlassian’s newer pages say spaces, work items and work types for projects, issues and issue types. This page uses both.

Any epic template has to fit Jira’s work type hierarchy. Atlassian’s hierarchy page says Jira starts with three levels:

• Level 1, Epic: larger pieces of work.
• Level 0, standard work types: story, task and bug in a software space.
• Level −1, Subtask: smaller pieces of a standard work item.

Three rules follow from Atlassian’s pages.

• Nothing goes under a sub-task. “A subtask can’t have any child work items”, in Atlassian’s words on What are work types? So an epic template is at most two levels deep: stories, then their sub-tasks.
• Sub-tasks belong under stories, not under the epic. An epic’s view offers child work items, not sub-tasks. Atlassian’s knowledge base lists ways a sub-task can still end up under an epic, such as a CSV import or moving one there, and calls that expected behaviour. A template should not rely on it: put the sub-tasks under a story or task.
• Levels above epic are a Premium and Enterprise feature. Jira admins on those plans can add levels above Epic. That changes what sits above your epic, not what goes under it.

Atlassian’s knowledge base has an example that does almost exactly this job: create multiple stories on an epic, and sub-tasks for one or more of them. It creates stories, re-fetches the work item data, stores the key of the story just created in a variable, and creates sub-tasks with that variable as their Parent. Its trigger is the epic moving to Done; for a template you want the epic being created. The outline below follows the same pattern.

The rule, step by step

1. Trigger: Work item created. Atlassian’s trigger reference names adding sub-tasks as one of its uses.
2. Condition: a JQL condition that matches only this kind of epic, for example issuetype = Epic AND labels = release. A JQL condition “checks to see if an issue matches a specified JQL query” (conditions). Without the label, every new epic gets the release breakdown.
3. Action: Create work item for the first story or task. Choose the work type, write the summary, and set Parent to the epic, {{issue.key}}. Atlassian’s action reference says this action “creates a work item of any type in a space” and accepts smart values.
4. Action: Re-fetch work item data, as the knowledge base example does before it reads the new key.
5. Action: Create variable, for example story1, set to {{createdIssue.key}}. Atlassian’s issue smart values page says {{createdIssue}} “accesses the previous issue created in the flow”, so it changes with every Create action. The variable holds on to this one.
6. Action: Create work item with the sub-task work type, once per sub-task, with Parent set to {{story1}}. The plain Create sub-tasks action sets only the summary; selecting Add fields turns it into this Create work item action.
7. Repeat steps 3 to 6 for each story, with a new variable name each time (story2, story3). A story without sub-tasks needs only step 3.

We wrote this outline from Atlassian’s pages and have not run this exact rule on our development site. Try it in a test space with one epic before you rely on it.

Smart values for the summaries

At the top level of the rule, {{issue}} is the epic that started it. That gives the children what they need from the epic:

• {{issue.key}}: the epic’s key, for Parent, or in a summary.
• {{issue.summary}}: the epic’s summary, as in Release notes for {{issue.summary}}.
• {{now.jiraDate}}: today’s date. Atlassian’s date smart values page says {{now}} is in UTC, so near midnight it can be a different day from yours.

Where the lists below say {{parent.summary}} on a story, write {{issue.summary}} in the rule.

When every story gets the same sub-tasks

If every story needs the same sub-tasks, such as “Write tests” and “Review”, there is a shorter rule. After the Create work item actions, add a branch over All created issues, which Atlassian’s branch reference describes as the work items made by Create or Clone actions earlier in the rule. Inside it, one Create sub-tasks action adds them to each story. The same page warns that branches over several work items run in parallel, “with no guarantee one will finish before the next one starts”.

Run it only when asked

A rule on Work item created runs for every new work item in its scope. If this kind of epic is rare, use the Manual trigger from work item instead. It runs when someone starts it from the work item’s Actions menu, and you can limit it to chosen groups (triggers). The person creates the epic, then runs “Add release work” on it.

Atlassian’s usage page counts every trigger, condition, action, branch and loop that runs as one step, against a monthly allowance for your organisation. The trigger is charged even when nothing matches. Our step billing guide has the allowances, the price over them, and the date extra usage billing starts.

How we counted: 1 for the trigger, 1 for the condition, 1 for each child, 2 more for each child with sub-tasks (re-fetch and variable), and 1 for each sub-task. The feature release is 1 + 1 + 6 + 10 + 13 = 31.

• Every other new work item costs too. A rule on Work item created runs its trigger and its condition for every new work item in its scope, epic or not: two steps, by the same rules. Three rules, one per kind of epic, make that six. The manual trigger avoids this.
• Size limit. Atlassian’s service limits allow 65 conditions, branches and actions in one rule (“steps per flow”). The audit epic above uses 34. An epic with twelve stories and forty sub-tasks would need 77, too many for one rule.
• Branches. The usage page does not say whether an action inside an All created issues branch counts once per story, so we have not estimated the shorter rule.
• Who can change the list. Atlassian’s permissions page says rules for one space are managed by its admins (Administer spaces and Browse spaces in a company-managed space, Administrator access in a team-managed one), and rules across spaces by people with Administer Jira, who can also turn off space admins’ access to rules. The person who knows the audit checklist is often not one of them.
• Who the work items come from. Changes a rule makes are shown as made by its flow actor, by default the “user” called Automation for Jira (flow actor).

Keep one epic that is never worked on, with its stories under it, and clone it. Atlassian’s Clone a work item page lists Child work items among the things a clone of an epic can include, and says you need the Create work items permission. The copy’s summary starts with “Clone”, it is linked to the original, and its children keep the reference epic’s wording. The page does not say whether the children’s own sub-tasks come with them, and we have not tested it, so we do not claim either way. It costs no Automation steps. Our sub-task guide covers cloning in more detail.

Each list is an epic’s children in order, with the sub-tasks under each. Type them into a rule, into our app’s template editor, or into a planning document; they read the same anywhere. Change the wording to your team’s and leave out what you never do.

{{parent.summary}} on a child means the epic’s summary, as our app writes it. In an Automation rule, write {{issue.summary}} instead. The sub-tasks have no placeholders, so they read the same in both.

Feature release

Epic summary:  Release [version], for example "Release 5.2"
Label:         release

1. Task: Code freeze for {{parent.summary}}
     - Announce the freeze date
     - Create the release branch
2. Task: Regression testing
     - Web app
     - Mobile apps
     - Public API
3. Story: Release notes for {{parent.summary}}
     - List the changes since the last release
     - Draft the notes
     - Product owner review
4. Task: Support briefing
     - Update the help articles
     - Brief the support team
5. Task: Deploy {{parent.summary}}
     - Deploy to staging
     - Deploy to production
     - Watch errors and alerts for an hour
6. Task: Announce {{parent.summary}}

6 children, 13 sub-tasks, 19 work items under the epic

Client onboarding

Epic summary:  the client's name, for example "Acme Ltd"
Label:         onboarding

1. Task: Kick-off with {{parent.summary}}
     - Agree goals and the go-live date
     - Name a contact on each side
     - Send the plan
2. Task: Accounts and sign-in for {{parent.summary}}
     - Set up single sign-on
     - Create the admin accounts
     - Check the first sign-in
3. Task: Data import
     - Test import
     - Full import
     - Check the totals with the client
4. Task: Training
     - Admin training
     - User training
     - Share the recordings and slides
5. Task: Go-live check with {{parent.summary}}
6. Task: Hand over to the account manager
     - Write the handover note
     - Introduction call

6 children, 14 sub-tasks, 20 work items under the epic

Quarterly audit

Epic summary:  Audit [quarter], for example "Audit Q4 2026"
Label:         audit

1. Task: Scope and evidence list for {{parent.summary}}
2. Task: User access review
     - Export the user list from each system
     - Managers confirm who still needs access
     - Remove access nobody confirmed
3. Task: Admin rights review
     - List every admin account
     - Remove admin rights nobody can explain
4. Task: Leavers check
     - Compare leavers with active accounts
5. Task: Backup restore test
     - Restore one system from backup
     - Record how long it took
6. Task: Policy review
     - Check each policy's review date
     - Send overdue policies to their owners
7. Task: Findings for {{parent.summary}}
     - Write up the findings
     - Agree an owner and a date for each action
     - Audit owner signs off

7 children, 14 sub-tasks, 21 work items under the epic

These are our suggestions, not Atlassian’s templates or a compliance standard. An audit list in particular should follow whatever your auditor or policy actually asks for.

We make Issue Templates & Create Defaults for Jira. That is why this page exists. This section follows its documentation as it stands on 21 October 2026. Child work items arrived in version 2.7.0.

An epic template with its children

In the template editor, under Child work items, you add each story or task, pick its work type and write its summary, then add sub-tasks under it. Up and Down set the order. Each child can have its own description, checklist, labels and priority, and the editor shows how many work items the template creates in all. The three lists above fit as they are.

Summaries and descriptions can use three placeholders: {{parent.key}}, {{parent.summary}} and {{today}}. On a child, the parent is the epic; on a sub-task, it is the child above it. Children can also set the assignee (Jira’s default, unassigned, or the person using the template), a due date a number of days ahead, components and some kinds of custom field (docs).

The editor follows Jira’s hierarchy: under an epic, standard work types; under those, only sub-tasks; nothing under a sub-task.

Creating the epic from the template

A pick on the project’s Templates page opens Jira’s own Create dialog filled in for the epic. The person checks it and creates the epic as usual, under Jira’s required fields and permissions. Once it exists, the page creates the children under it, then the sub-tasks under each, in the template’s order, and shows how far it has got. For a work type with a default template, the Create dialog names the default; the app writes nothing into a form by itself.

Adding the breakdown to an epic that already exists

••• → Add work items from template on an existing epic previews what will be created, in order, with the placeholders filled in, and then adds it. The epic itself is not changed, and nothing already under it is touched. Our guide to adding the same sub-tasks to an existing work item covers this case with Jira alone too.

When Jira says no

Every work type is checked against the project before anything is created. Jira can still refuse an item, for example when its work type needs a field the template does not fill. Everything created so far is kept, and the person can Resume after fixing the cause, with nothing created twice, or Skip that item and the sub-tasks under it.

The app does not use Jira Automation, so its runs count nothing towards your Automation usage. The work items are created with the permissions of the person using the template.

• A person or a rule starts it. It acts when a person picks a template on the Templates page or runs Add work items from template, or when an Automation rule runs the app's Add work items from template action, for example on Work item created. A rule run that does not finish a large tree leaves the rest to resume from the epic's ••• menu.
• Two levels. Children under the epic and sub-tasks under them, like Jira itself. Up to 30 children, 20 sub-tasks per child, and 100 work items in one template.
• Not every field. No versions, no user-picker fields and no named assignee. A required field the template does not fill makes Jira refuse that item.
• Not for service projects. Atlassian lists the Create dialog support the app uses for software and business projects. Service projects and Jira Product Discovery are not on that list, and we have not tested them.
• Jira Cloud only. Not Data Center or Server.

If one kind of epic always gets the same breakdown, an admin owns the list, and the step cost is fine, the Automation rule above is enough and costs nothing extra to install. The app earns its place when people should choose between several epic templates, or edit them without being Automation admins.

Our plain advice: write the breakdown down first, using the lists above as a start. If it is one list for one kind of epic, an Automation rule run by hand is cheap and enough. If there are several, and the people who know them are not Automation admins, try an app.

Can Jira create the stories and sub-tasks when an epic is created?

Yes, with an Automation rule on Work item created and a condition that picks out the kind of epic. Create work item actions add each story with the epic as its parent, and more Create work item actions add the sub-tasks under each story, using a variable that holds the story’s key. The children appear after the epic is created, and every run counts towards your Automation usage.

Can a sub-task go directly under an epic?

Not as Jira is normally used. In the default hierarchy, stories, tasks and bugs go under an epic and sub-tasks go under those, and an epic offers child work items rather than sub-tasks. Atlassian’s knowledge base lists a few ways a sub-task can still end up under an epic, such as a CSV import or moving it there. A sub-task cannot have child work items.

How many Automation steps does an epic rule use?

One for each trigger, condition, action, branch and loop that runs. By Atlassian’s counting rules, the feature release example on this page comes to an estimated 31 steps per epic. A rule on Work item created also uses its trigger and condition, two steps, for every other work item created in its scope.

Does the Issue Templates app fill in Jira’s Create dialog by itself?

No. A pick on a project’s Templates page opens Jira’s own Create dialog filled in, and for a work type with a default template, the Create dialog names the default. The app writes nothing into a form by itself and sets no default values for fields.

Can the app add the stories to an epic that was created another way?

Yes, when someone asks it to: Add work items from template, in the epic’s ••• menu, previews the stories and sub-tasks and adds them under it. The app also adds an action to Jira Automation, Add work items from template, so a rule can do the same when an epic is created or changes status.

• Jira issue templates in Jira Cloud: the hub. Default descriptions, block templates, Automation, cloning and request types, and where each stops.
• Jira templates with sub-tasks: the same sub-tasks under every new work item.
• Jira epic template with stories and sub-tasks: this page.
• Add the same sub-tasks to an existing Jira work item: by hand, with a rule run from the work item, or with an app.
• Jira default description: a description template for each work type.
• Jira employee onboarding template with sub-tasks: the same steps for every new starter.

Also useful:

• Jira epic template: free text for the epic’s own description and checklist.
• Child work items and sub-tasks: how the app sets them up and creates them, in its documentation.
• Recurring tickets in Jira Service Management after Automation step billing: what Automation steps cost.

Every statement about Jira on this page comes from the Atlassian pages below, read on 21 October 2026. Where Atlassian’s pages did not say something, we left it out or said so. Step counts are our estimates from Atlassian’s counting rules, not measurements. The three child lists are our own suggestions.

• Create multiple stories on an epic and create subtasks for one or more story issues (KB) (checked 21 Oct 2026, last updated 25 Sep 2025)
• Jira automation triggers (checked 21 Oct 2026)
• Jira automation conditions (checked 21 Oct 2026)
• Jira automation actions (checked 21 Oct 2026)
• Jira automation branches (checked 21 Oct 2026)
• Automation smart values: issues (checked 21 Oct 2026)
• Automation smart values: date and time (checked 21 Oct 2026)
• How is your automation usage calculated (checked 21 Oct 2026)
• Automation service limits (checked 21 Oct 2026)
• Permissions required to manage automation flows (checked 21 Oct 2026)
• What is a flow actor? (checked 21 Oct 2026)
• Configure the work type hierarchy (checked 21 Oct 2026)
• What are work types? (checked 21 Oct 2026)
• Jira Epic issues have subtasks under them along with child issues (KB) (checked 21 Oct 2026, last updated 26 Sep 2025)
• Clone a work item (checked 21 Oct 2026)

Changelog

• 21 October 2026. First version.

Corrections

None yet. If something here is wrong, email [email protected]. We will fix it and say so here.