Jira issue templates without an app: five native options, and how to judge an app if you still need one
Jira Cloud has no template picker in its Create dialog, and the two tickets asking for one have been open for years (JRACLOUD-7731 for issue templates, JRACLOUD-4812 for default values, with about 2,800 votes). What Jira does have is five things that each get part of the way, and most answers on this forum skip at least two of them, including the two that need no app at all. Below: what each does, the exact point where it stops, and then, for the cases an app does solve, four questions and seven tests that tell template apps apart, ours included. Everything was checked on a Cloud site this week.
First, which of three things do you want?
"Template" means one of three jobs:
- Text. Every new Bug starts with "What happened / Steps / Expected"; every Story with a user-story line and acceptance criteria.
- Structure. Every release is an Epic with the same six tasks and their sub-tasks; every new starter is a Task with the same twelve sub-tasks.
- Defaults. Labels, priority, a due date, a component, a custom field, set the same way every time without anyone typing them.
Jira's own options cover the first well, the second partly, and the third barely. Keep your job in mind while reading; it decides whether you need an app at all.
A default description per work type
Team-managed space: Space settings → Work types → pick the type → open the Description field → Default description. Every new work item of that type opens with that text in the Create dialog, and people edit it before pressing Create.
Company-managed space: the system Description has no default. Atlassian's documented workaround is a paragraph custom field with a default value on the Create screen, copied into Description by a workflow post function. The lighter alternative is an Automation rule on Work item created that edits the description; put {{issue.description}} into the rule so it keeps what the person typed, and accept that the text appears a few seconds after creation rather than in the dialog.
Where it stops: one text per work type, no choice between templates, no fields set, no sub-tasks.
Block templates in the description
In any work item description, type / and start typing a template name, or open the Insert menu and type "template", then pick one. The content lands in the description as ordinary text to edit. Jira ships some; your own are created in Confluence, not in Jira, and each insertion is a manual step by the person writing.
Where it stops: it is a snippet library, not a template for the work item. Nothing is applied automatically; nothing outside the description is touched.
A bookmark that opens Create already filled in
This is the one most answers get wrong. Jira Cloud still honours the old Create link, and it takes more than the space and work type. A bookmark like
YOUR-SITE.atlassian.net/secure/CreateIssueDetails!init.jspa?pid=10000&issuetype=10001&summary=New%20story&description=Definition%20of%20ready%0A-%20Item%20one%0A-%20Item%20two&labels=dor&priority=3
opens the full-page Create screen with the summary, the description, the label and the priority already filled in; you change the title and press Create.
The ids come from YOUR-SITE.atlassian.net/rest/api/3/project/KEY?expand=issueTypes while you are logged in ("id" is the space's id, each "issueTypes[].id" a work type's). %20 is a space and %0A a line break.
Where it stops: the description arrives as plain text (wiki markup such as h3. or * shows up literally; line breaks are kept), it is the older full-page screen rather than the dialog, and it cannot add sub-tasks or fill a field that belongs to a checklist app. For a Definition of Ready kept as lines in the description, it is a genuine one-click bookmark.
Clone, with the children
Jira's own Clone dialog on an epic offers three things to include: Attachments, Child work items and Links. Keep one "template" epic with its tasks and sub-tasks, open it, choose ••• → Clone, tick Child work items, and the whole structure is copied.
Where it stops: every copy keeps the template's summaries, so each one is renamed by hand; nothing is filled in per release; and the template epic lives on a board, where people find it, move it or close it. Clone copies a shape. It does not know it is a template, and it cannot tell you when the shape no longer fits the space.
A manual Automation rule
A rule with a manual trigger and one Create work item action per task, each with Parent set to the trigger work item, builds the same structure from any epic's Actions menu, with the summaries written once in the rule. Put {{issue.summary}} into a child's summary and it carries the epic's name. Jira's own template library has a starting rule for this.
Where it stops: the rule is the template, so changing the structure means editing the rule; a rule belongs to one space unless you make it global; and on Standard plans each run counts against the monthly rule limit.
A variation, suggested by Mertcan in the comments: trigger the rule on Work item created, add a condition on the work type, and use Create sub-tasks. The sub-tasks appear by themselves and there is no template epic to go stale. The catch: it runs on every work item of that type, whether or not it needs them, and Create sub-tasks only sets each sub-task's summary unless you switch it to Create work item through Add fields.
A note on "field suggestions"
Since late October, Jira can suggest labels, an assignee and a priority when you create work, based on similar work items. It is useful, and it is not a template: nothing is filled in unless the person accepts the suggestion, and it does not know your process.
Which option for which job
Your job | Use |
One text per work type, in the dialog | Default description (team-managed) or the custom-field workaround (company-managed) |
Several texts to choose from | A Create-link bookmark per text |
The same structure every time | Clone with Child work items, or a manual rule |
A few defaults such as labels or priority | A Create-link bookmark |
Any of these across several teams, kept in step as spaces change | An app |
How to judge an app, including ours
If you reach this point you are choosing among a dozen Marketplace apps whose listings all say "templates". Four things separate them more than any feature list, and all four are checkable.
- Does it write into the Create dialog by itself? Most do: the moment a work type is chosen, the form fills. People love it, and it is behind the sharpest one-star reviews in the category, because Jira can re-run an app's code on a form that already holds text, for example when a minimised dialog is restored or the work type is changed. The alternative design is a pick: the person chooses the template and Jira's dialog opens filled in, or the dialog names the default and the person opens it. Neither is wrong. Decide which you want first, because no setting changes it later.
- Who creates the work items, and what happens when one fails? A template with children creates several work items in a row. Ask whether they are created by Jira as the person (so Jira's permissions, required fields and workflow apply) or by the app as itself, and what happens when the third of eight is refused because a work type was renamed or a field became required. The honest answers are "it stops and tells you", "it resumes without duplicates" or "it is not transactional". Reviews about children "created out of order" or "orphaned" are about this.
- Where does the template data live, and what leaves Atlassian? The Runs on Atlassian badge on a listing means the app's compute and storage are on Atlassian's platform and nothing is sent outside it. Not every template app has it: some keep template definitions on their own servers, some send usage analytics to a third party. The listing's Privacy & Security tab has each vendor's answers on storage, residency and retention, and the install screen lists every permission scope; across the category the count runs from six to twenty.
- Does it tell you when a template stops working? Spaces change. A work type gets renamed, a field leaves the create screen, a component is deleted, and a template that worked in March fails in June for the first person who needs it. Reviews with "stopped working" in them are about this. Ask whether anything checks the templates against the spaces, and how you hear about it.
Seven things to test in a trial
All of this fits in an afternoon on a throwaway space.
- Order and parents. Make a template with an epic, three tasks and two sub-tasks each, use it twice, and check the keys arrive in template order under the right parents.
- A failure half-way. Make a field required on the third task's work type, use the template again, and see whether the app stops and says why, resumes without duplicates, or leaves half a tree.
- Your own text. If the app fills the dialog by itself, type a summary, minimise the dialog, restore it, and change the work type. Your text should survive all three.
- Drift. Rename a work type the template uses, or take a field off the create screen, and see whether the app tells you, and when.
- The install screen. Count the scopes and read what each is for.
- Who may manage. Sign in as a project administrator who is not a Jira administrator and try to make, change and delete a template.
- Moving house. If you have a second site, export from one and import into the other.
Disclosure, and where our app fits
I build Issue Templates & Create Defaults for Jira, so the four questions above are also the ones we built the app around; read this paragraph with that in mind. It takes the pick design: a template per space, listed on a Templates page, and Create there opens Jira's own Create dialog with the description, checklist items, labels, priority, assignee, due date, components and custom fields filled in; the child work items and sub-tasks are created afterwards, in order, with placeholders such as {{parent.summary}} filled in, and a refused item stops the run with Jira's reason so it can resume or be skipped. A daily check tests every template against its spaces and names what stopped working. It runs on Atlassian with six scopes and sends nothing outside. What it does not do: fill the dialog by itself, serve the Jira Service Management portal, or copy attachments. If one of the five options above does your job, use it; it costs nothing and stays when any app is gone.
https://marketplace.atlassian.com/apps/2217571549/issue-templates-create-defaults-for-jira
Which of the five do you use today, and where did it stop for you? I'll add the cases I've missed to this post.
