Issue Templates & Create Defaults documentation

Templates for new Jira issues, opened in Jira's own Create dialog from a project's Templates page. What administrators set up, what people see, and what the app keeps.

Documentation for Mermaid Diagrams & Gantt Recurring Requests Issue Templates

The app fills in a new issue's summary, description, checklist, labels and priority from a template. People pick a template on a project's Templates page, and Jira's own Create dialog opens with it filled in. For the issue types you choose, Jira's Create dialog also names a default template under Summary. The app writes nothing into that form by itself.

A template can also create child work items, and sub-tasks under them, in the order you set: under the work item it makes, or under one that already exists. See Child work items and sub-tasks.

It adds no custom fields, and it never changes an issue after it has been created.

On this page

• Getting started
• Making a template
• Default templates in the Create dialog
• The Templates gallery
• Child work items and sub-tasks
• Assignee, due date and components
• Save as template
• Who can do what
• The health check
• The daily check and the alert issue
• Moving templates to another site
• Version history
• Recently deleted
• Usage counts
• Limits, and where templates do not apply
• Licensing
• Your data, and uninstalling

Get started, in the app. After installing, the Get started button in Manage apps opens the app's page, which shows two steps at the top: add a template (three examples in one click, your own, or Save as template), then create a work item from it on the project's Templates page. Each step ticks itself once it has really happened, and the steps go away after the first work item made from a template, or sooner with Hide these steps. A project's settings page shows the same steps for that project. Everything below is the long version.

Installing the app changes nothing in the Create dialog. Until a template is made the default for an issue type, the app only adds its pages and its daily check. The pages are a Templates page in each project, the same gallery under Apps, Save as template in each issue's ••• menu, and the pages where templates are managed. The daily check looks at your templates once there are any; see The daily check.

Templates are managed in two places:

• Jira settings → Apps → Issue Templates & Create Defaults — every template on the site. Only Jira administrators can open it.
• Project settings → Templates — the templates used in that project. Project administrators manage their own project's templates here without needing a Jira administrator.

Example templates in one step. On either page, Add example templates adds three to a project: a bug report, a task that creates its sub-tasks, and a release epic that creates its stories, tasks and sub-tasks. They are built from the project's own work types, so a project without a Bug type gets no bug report, and an example the project already has is skipped. They are ordinary templates: edit or delete them like any other. On the Jira settings page, choose the project first.

A first template of your own:

• Choose New template. Give it a name, choose the projects it can be used in (on a project's settings page it is for that project), and the issue types it is for.
• Under Default for these issue types, choose the issue types whose Create dialog should name this template. Leave it empty for a template people only pick from the Templates page.
• Fill in what new issues should start with, and choose Save template. The Create dialog in those projects is updated as you save.
• Try it: open the project's Templates page (a tab or a sidebar entry, depending on the project) and press Create on the template. Jira's Create dialog opens with it filled in. Opening Create in Jira with a default's issue type shows the line naming the default under Summary.
• Under Will every template work?, press Check now. It tells you whether each template works in every project it is for.

The quickest start is often an issue you already like. Open it, choose Save as template from its ••• menu, and tick the box to make it the default for that issue type. See Save as template.

The editor has these parts.

A template needs at least one thing to fill in: a summary, a description, a checklist, labels or a priority. Text over a length limit is cut to fit, and items over a count limit are left off, when the template is saved. A site can hold up to 200 templates.

Saving updates the Create dialog. When you save or delete a template, the app rewrites the Create dialog settings of each project it is in. If a project cannot be updated, the page says which one and why. Rebuild Create dialog settings, below the list of templates, does the same when you ask: for every project a template is used in, from the Jira admin page, or for one project from its settings page.

Delete asks you to click again before it deletes. A deleted template can be restored for 30 days; see Recently deleted.

A template can be the default for some of its issue types. When someone opens Jira's Create dialog, with the Create button or the c key, and chooses one of those issue types, the app adds one line to the Summary field's help text. For a template called "Bug report" it reads: Default template for this work type: "Bug report". To use it, open Templates in the project sidebar.

The app writes no field value. Summary, description, labels and priority stay as Jira and the person leave them. To start from the template, open Templates in the project sidebar and pick it; see The Templates gallery.

When the line appears

• Jira runs the app when the dialog opens, when the person changes the issue type or the project, and after each issue created with Create another ticked. Each time, the line names the default of the issue type now chosen.
• An issue type with no default gets no line.
• If someone has already written a summary or description at that point, no line is added.
• A Create dialog opened from the Templates page gets no line.
• Without an active licence, no line is added.

Where the line shows depends on the dialog. In Jira's compact Create dialog it sits behind the small (i) icon next to Summary. In the full Create dialog it shows under the field. If an administrator already wrote help text for Summary, that text stays, and the line is added after it.

Why the app does not fill the form

Jira can run an app again on a Create dialog that was minimised and restored, and report an empty summary and description while the person's text is on screen. An app that fills an empty form would then replace that text. Until Jira tells apps which form they are on, the app names the default and writes nothing.

Earlier versions filled the form and added a note to each field they filled. Those notes no longer appear.

Each project gets a Templates page. In current Jira it appears as a tab in the project's navigation. It lists that project's templates, whether or not they are a default. The same gallery, for every project the person can see that has templates, is under Apps in Jira as Issue Templates & Create Defaults.

Each template shows its name and summary, how many checklist items and which labels it has, and which issue types it is the default for. Choose the issue type if more than one fits, then Create.

Create opens Jira's own Create dialog with the summary, description, checklist, labels and priority filled in. The person can change anything before creating. Jira then does what it always does: its permissions, required fields and workflow apply, and the app never creates the issue itself. Afterwards the gallery shows the keys of the issues created.

After the dialog opens, the app writes nothing more into it, even if the issue type is changed, and adds no line under Summary. The rare cases where that line can still appear are listed under Limits.

Anyone who can see a project can open its gallery. Only issue types the person can see are offered, and subtask types never are. Creating the issue still needs Jira's Create issues permission. With no templates to show, the page says No templates here yet and explains who can add them.

A template can list work items to create under the one it makes: for an epic, its stories and tasks, and sub-tasks under each. They are created one at a time, in the order the template lists them: each child, then its sub-tasks, then the next child.

Setting them up

In the template editor, under Child work items, choose Add child work item, pick its work type and write its summary. Add sub-task adds a sub-task under it. Up and Down change the order, and Details opens its description, checklist, labels and priority. The editor shows how many work items the template creates in all.

What fits depends on the work type the template is for, as in Jira itself. Under an epic, standard work types (story, task, bug) go; under a standard work type, only sub-tasks; and nothing goes under a sub-task. So a tree is at most two levels below the work item it starts from.

A summary or description can use three placeholders, filled in when the work item is created:

• {{parent.key}}: the key of the work item it goes under, for example CP-5.
• {{parent.summary}}: that work item's summary.
• {{today}}: the date, as 2026-10-21.

For a child, the parent is the work item the template made or was added to. For a sub-task, it is the child above it.

From the Templates page

A template with child work items says creates N work items under it on its card, and Show the work items it creates lists them. Create opens Jira's Create dialog for the top work item as usual. Once it is created, the page adds the child work items under it and shows how far it has got, then the keys of everything created. Keep the page open until it says so. If it is closed early, what was created is kept, and the rest can be added from the work item's ••• menu.

On a work item that already exists

In a work item's ••• menu, Add work items from template lists the project's templates that have child work items. Pick one to see what will be created, in order, with the placeholders filled, and any work type that does not fit this work item. Create adds them under it. The work item itself is not changed, and nothing already under it is touched. A run that stopped part-way is listed there as Unfinished, with Resume.

From a Jira Automation rule

The app adds an action to Jira Automation: Add work items from template, under Other apps when you add an action to a rule. It does what the ••• action does, for the rule's work item.

• The first time, Jira asks you to Connect the rule to the app. The action then runs as that connection's user, with their Jira permissions.
• In the action, choose the template and the work item, usually {{issue.key}}: the rule's own work item. For example: when an epic is created, add the release template's stories and sub-tasks under it.
• One rule run creates what it can in about 20 seconds; small trees finish in one go. A larger one is left as Unfinished on the work item, to resume from its ••• menu.
• If Jira refuses an item, the action fails with Jira's message, and the rule's audit log shows it. What was created is kept.
• The action passes created, total, status and runId on to later steps of the rule.

A second action, Create work item from template, creates the template’s own work item too, so a rule can start work without an existing work item: for example, a scheduled rule that creates the weekly operations checklist every Monday.

• Choose the template, the project (usually {{project.key}}: the rule’s project) and, when the template fits more than one work type there, the work type by name. The template must be used in that project.
• Summary is added after the template’s own summary, and smart values work there, for example {{now.jiraDate}}: a template whose summary is “Release ” then creates “Release 2026-11-02”.
• The work item gets what a pick on the Templates page puts in Jira’s Create dialog: summary, description with its checklist, labels, priority, assignee, due date, components and custom fields. “The person using the template” is the rule’s user. Then its child work items follow, in order, as above.
• Work types are checked before anything is created. A field that is not on the work type’s create screen is left out, and the rule’s audit log names it.
• It passes key (the new work item), and created, total, status and runId for its children, on to later steps.

When Jira refuses an item

Before anything is created, every work type is checked against the project. Even so, Jira can refuse an item, for example when its work type needs a field the template does not fill. The run then stops at that item and shows Jira's message. Everything already created is kept. You can:

• Resume, after fixing the cause, such as a permission or a required field. Nothing is created twice, even if the page was closed while an item was being created.
• Skip this item, when the template itself is the cause. That item and the sub-tasks under it are left out, the rest is created, and the result names what was skipped.

A run keeps the template as it was when it started, so editing the template does not change a run already under way. If a work type's create screen lacks labels, priority or description, the item is created without that field, and the result says so.

Child work items are created with the permissions of the person using the template, and they need Jira's Create issues permission in the project.

A template, and each of its child work items, can also set three fields. They are under the labels and priority in the editor, and in a child's Details.

• Assignee: Jira's default (the project's default assignee, if it has one), unassigned, or the person using the template. No one is chosen by name: the app reads who is using the template at that moment and does not keep it.
• Due date: a number of days after the work item is created, from 0 (the same day) to 365.
• Components: by name, comma-separated. Each project has its own components, so they are matched by name in the project the work item is created in. A name the project does not have is left out, and the page says so.

A pick on the Templates page fills them into Jira's Create dialog, where the person can change them. "Unassigned" applies to child work items; in the Create dialog the app leaves the assignee as Jira sets it. Child work items get their settings when they are created. If a work type's create screen lacks one of these fields, or Jira will not assign the person, the item is created without it and the result says so.

Custom fields

Under Add a custom field, the editor offers the custom fields on the chosen projects' create screens that the app can set: short text, paragraph, number, date, dropdown and radio buttons, multi-select and checkboxes, labels and URL. A child work item offers only the fields its own work type has. User pickers, cascading lists, teams and app fields are not offered.

• A date is a number of days after the work item is created.
• Options are kept by name, so the same template works in projects whose fields have their own option lists. A Templates page pick looks the option up in that project; an option the project does not have is left out.
• If Jira refuses a value for a child work item (the field is not on its create screen, or the option is not available there), the item is created without it and the result names the field.

Open an issue and choose Save as template from its ••• menu. It makes a template from the issue's description and labels, and its priority if you choose. The issue itself is not changed.

To start from a common structure, the free Jira issue template generator writes bug report, user story, incident and other templates you can paste into an issue first.

Jira administrators can use it on any issue, and project administrators on issues in their project. Anyone else who opens it is told who can.

• Template name starts as the issue's summary, cut to 80 characters.
• Summary new issues start with is empty until you fill it in, for example "Bug: ". The issue's own summary is not used for new issues.
• Use this issue's description, with its formatting is on. A preview shows what will be kept.
• Labels is on and Priority is off, when the issue has them.
• Make this the default template for Bug in KEY is off. Tick it to make the template the default for that issue type in that project, so Jira's Create dialog names it.

The template is made for the issue's project and issue type. If the issue is a subtask, the template is for any issue type in the project, and it cannot be a default.

What is kept, and what is left out

Kept: paragraphs, headings, bullet and numbered lists, code blocks, quotes, dividers, panels, tables, action items (unticked again), decisions, expands, emoji, status lozenges, dates and link cards, with bold, italic, underline, strikethrough, code, links, subscript, superscript, text colour and highlight.

Left out, and counted in a Left out: line under the preview:

• @mentions, because they identify people.
• Attachments and images, because the files belong to that issue.
• Links to a person's profile, email links, and email addresses in the text. A text link keeps its words and loses only the link. An address in the text is replaced with "[email removed]".
• Content from other apps, such as their macros.
• Anything else a template cannot carry, such as layout columns, which are left out together with what is in them.

The alignment and indentation of paragraphs and headings, and any other formatting not listed above, are not kept either, and are not counted.

Read it before saving. The cleaning finds mentions, profile links and email addresses, and it runs only on a description saved from an issue. Nothing else is scanned: not the template name, summary, checklist or labels, and not a plain description typed in the editor. A name written as ordinary words stays, and the template name starts as the issue's summary. If either names a person, change it.

A very long formatted description is refused, with a message asking you to shorten it on the issue or use a plain description.

Before it opens a management page or changes a template or a setting, the app asks Jira what the person may do. Two roles matter: Jira administrators, who have Jira's Administer Jira permission, and project administrators, who have Administer projects in that project.

A shared template is one used in more than one project. Sharing is changed only on the Jira admin page. A template a project administrator makes belongs to their project alone.

A project's settings page shows only templates used in that project, and its health check looks at that project only. It does not show a project administrator the names or keys of other projects a shared template is used in, only their numeric project ids.

Everyone else: anyone who can see a project can use its gallery, and anyone with Jira's Create issues permission there sees the default template named in the Create dialog.

Below the templates, Will every template work? → Check now tests each template in each project it is for. It only reads; nothing is changed. Each template is marked works, check or broken, with a line for each problem and its usage counts.

On the Jira admin page it covers every template, in up to 60 projects per check; if there are more, the page says so, and the daily check covers up to 1,000. On a project's settings page it covers that project.

What it can report, and what to do:

It does not check whether a template's priority is in the project's priority scheme, or whether the create screen has a Summary field.

After adding an issue type to a project that has default templates, press Rebuild Create dialog settings. The app runs only for the issue types a project had when its settings were last rebuilt, and rebuilding adds the new one.

Once a day the app runs the same check by itself, across up to 1,000 projects. It cannot be switched off, but it pauses without an active licence (see Licensing). It changes nothing in your Jira configuration, and it records nothing about who uses the app. With the alert switched on, it also creates one issue when it finds something new; see The alert issue.

When it finds a problem that was not there at the previous check, it lists it under Daily check → Recent findings at the bottom of the Jira admin page, and a banner at the top of the page says so until someone chooses Dismiss. A problem is reported once, and not again while it stays the same. If it clears and later comes back, it is reported again. The first check reports every problem that already exists, once, as its starting point.

If Jira was busy or failing during a check, that check records nothing, and the next one compares with the last complete check.

Run the daily check now runs it straight away, so you can see the result without waiting a day. It counts as a check: what it finds is not reported again the next day.

The alert issue

Off by default. To be told in Jira as well:

• Switch on Also create a Jira issue when something stops working.
• Choose the Project for alert issues and an Issue type. Pick a type that needs nothing but a summary and a description, because those are the only fields the app fills.
• Choose Save, then Send a test alert. It creates an issue called "Issue Templates: test alert (nothing is wrong)", so you can see where alerts will land. Its description only explains that it is a test. Delete it afterwards.

A real alert is called, for example, "Issue Templates: 2 templates stopped working", counting the templates affected. Its description lists each template with a Broken or Check line for each problem, and says where to fix them. It holds template names, project names and keys, and issue type names, and nothing about who uses the app. The app creates the issue as itself.

An alert issue is created only when a check finds something new that has stopped working, and a check creates at most one. That includes a check started with Run the daily check now. If Jira refuses to create it, for example because the issue type needs another field, the reason is shown under Recent findings and those problems are not sent again. That is why the test alert is worth sending first.

Alert issues are the only issues the app ever creates. It never edits or deletes an issue.

On the Jira settings page, Move templates to another site exports every template as text and imports an export. Use it to move a client's templates from a test site to production, or to keep a copy. Only Jira administrators can use it.

• Export all templates gives the text to copy and keep as a .json file. Projects are written as their keys, the priority by its name and custom fields by their names, so the export does not depend on this site's internal ids.
• To import, paste an export and choose Check. Nothing is saved yet: each template is listed with what does not fit this site, such as a project key, priority or custom field it does not have. Those parts are left out, never guessed.
• Import then saves the templates that fit, with the same checks as the editor. A template whose name already exists in one of its projects is skipped, never overwritten.

An export holds the templates' text as your administrators wrote it. Keep it where you keep other configuration backups.

History on a template lists its saved versions, newest first: the version number, the date and time it was saved, and what changed, such as "changed summary, labels" or "restored version 3". Who saved it is not recorded.

Show displays a version. Restore this version saves it again as the newest version, so going back loses nothing: the version you left stays in the list. A restore goes through the same checks as any save. For example, it is refused if another template has since become the default for the same issue type.

The last 50 versions of each template are kept. A save that changes nothing adds no version. History is open to whoever may edit the template.

A deleted template leaves the Templates pages and the Create dialog settings straight away, and appears under Recently deleted for 30 days. Restore brings it back with its history and usage counts, and puts it back into the Create dialog settings. After 30 days it can no longer be restored, and it is removed together with its history and counts.

The Jira admin page lists every deleted template. A project's settings page lists, for its project administrators, the ones that belonged to that project alone.

Each template, in the list of templates and in the health check, shows a line such as Used: created from the gallery 3 times · last 22 Sep 2026, or Not used yet. These are numbers and a date. Nothing records who used a template.

• Filled in automatically can also appear in that line. It counts the times earlier versions of the app filled the Create dialog with the template. It no longer goes up.
• Created from the gallery goes up once each time someone pressed Create on the template in the gallery and created at least one issue from that dialog.
• Counts can come out slightly low, because two uses at the same moment may be counted as one.
• The app also keeps one count for the whole site: how many times a template was used from a Templates page, and the date of the first. After 10 such uses over at least 14 days, the Templates page may ask for a rating on the Atlassian Marketplace, under the message that something was created. Rate it opens the listing’s reviews; Not now puts it off for 60 days, and after the second time it is not asked again. Your browser keeps only that answer.

Only in Jira's Create dialog. A template is filled in when it is picked on the Templates page, which opens Jira's Create dialog. The line naming a default appears only in that dialog. Issues created any other way get neither: inline on a board, backlog or list, by email, through the REST API or Automation rules, by import or cloning, from the mobile apps, or from a service project's portal.

Atlassian lists these ways into the Create dialog: the Create button, the c keyboard shortcut, and an app's own Create button, like the gallery's. Add a child issue and Create subtask open it only when the issue type requires a summary and at least one other field.

• Which fields. A template fills Summary, Description with the checklist, Labels and Priority, and can set the assignee, a due date, components and custom fields (how). Not versions, user-picker fields or a named assignee.
• Sub-tasks come from a parent. Sub-task work types are never offered as the top work item in the gallery. A template creates sub-tasks as part of its child work items.
• Project types. Atlassian documents the Create dialog support this app uses for company-managed and team-managed software and business projects. Service projects and Jira Product Discovery are not on that list, and we have not tested them.
• A moment after opening. Jira runs the app once the dialog has loaded, so the line under Summary can take a few seconds to appear.
• Gallery picks. The gallery marks its pick in that browser tab, so its Create dialog gets no line. If the browser blocks site storage for apps, the mark is missing: a picked template that is also a default can then get a line naming the chosen issue type's default. For up to two hours after a gallery dialog that Jira did not report closing, Create dialogs in that tab get no line.
• Other apps. Up to five apps can change the Create dialog at once. This app sets no field values there. It only adds its line to the Summary field's help text, after any help text already there.
• Issue types are matched by name. If you rename an issue type, edit the templates that name it. The health check lists them.
• The checklist is Jira's own action items in the description, not a separate checklist field.
• Numbers. 200 templates per site. 50 projects and 30 issue types per template. Up to 30 child work items per template, 20 sub-tasks under each, and 100 work items in all. One default per issue type per project. Project lists and the Apps gallery show up to 500 projects. The priority list shows up to 50 priorities. A check from the page covers up to 60 projects, the daily check up to 1,000.
• One project's defaults together must fit in Jira's limit of 50,000 characters for Create dialog settings. If they do not, the template is still saved, but that project's Create dialog is not updated and keeps its previous settings. The page lists the project with The default templates for this project are too long for Jira to carry.

Without an active licence, for example after a subscription ends:

• Templates cannot be saved, restored, or made from an issue.
• The gallery shows This app needs an active licence.
• The Create dialog names no default template.
• The daily check does not run on its schedule.

Your templates are kept. The admin and project pages still open, with a warning, so you can see your templates and their history, delete them, and run the health check.

The app records nothing about the people who use it. It keeps templates and numbers. It never records who made, changed, used, restored or deleted a template, or anyone's account ID. A template holds whatever your administrators type into it or copy from an issue, so it holds personal data only if someone puts it there. See Save as template for what is taken out of a copied description.

Not kept anywhere:

• Who created, edited, restored, deleted or used a template. The app adds no account IDs, names or email addresses of its own. A template holds them only if someone types them in or copies them from an issue. From a copied formatted description, Save as template removes @mentions, attachments, other apps' content, profile and email links, and email addresses. A name written as ordinary words stays (see Save as template).
• What people type in the Create dialog. The app looks at the summary and description in the browser only to decide whether to add the line naming the default.
• Which issue a template was saved from. Its key is not kept, only what you chose to copy into the template. The keys of issues created from the gallery are not kept either.

Nothing is sent outside Atlassian. The app declares no outside connections, and every request it makes goes to your own Jira site or to the app's own functions on Atlassian's platform.

Data residency

In scope: everything the app keeps in Forge storage. That is templates, their versions, deleted templates, usage counts, and the daily check's settings and findings.

Out of scope: the Create dialog settings, which Jira stores through its UI modifications feature, and alert issues, which are ordinary issues in your Jira project. Neither is kept in the app's storage. Nor are the error log lines, or the picked template's text that the gallery keeps in the person's browser tab while its Create dialog is open. Both are listed in the table above.

Uninstalling

Once the app is uninstalled, the Create dialog no longer names a default, and its pages, the gallery and the daily check are gone. Alert issues stay, because they are ordinary issues in your project.

The app has no step of its own that erases data when it is uninstalled. Its Forge storage belongs to its installation on your site, and what happens to it afterwards follows Atlassian's rules for Forge apps.

To take the Create dialog settings out of Jira before you uninstall, clear Default for these issue types on every template, or delete the templates. The app removes a project's record as soon as the project has no default templates.

More in our privacy policy.

Email [email protected] with the template name, the project key and issue type, and what you expected to happen. What the health check says helps too. First reply in 1-3 business days, depending on severity (see our service level agreement).