Jira default description: a description template for each work type

Every new bug should start with the same headings: steps to reproduce, expected result, actual result. Here is how to give a Jira Cloud work type a default description, what Jira allows in each kind of space, and where an app fits.

By Rolf Eriksen Published 21 October 2026 10 min read

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

Short answer

Team-managed space: yes. A space admin can give each work type its own default description in the space settings. People see it in the Create dialog.
Company-managed space: not for the system Description field. Atlassian’s workaround uses a stand-in Paragraph field with a default value and two workflow post functions. It works, but it changes a custom field, a screen and a workflow.
Either kind: an Automation rule can write the template into Description after the work item is created. The person creating it does not see the template while they type.

Each of these gives a work type one starting text. If one fixed description per work type is all you need, use them; you do not need an app. This page is part of our guide to Jira issue templates in Jira Cloud, which covers the other native options.

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.

Team-managed spaces: a default description per work type

Atlassian’s knowledge base says a default description template for new work items is available in team-managed spaces, and not in company-managed ones (KB). Atlassian’s recap on JRACLOUD-4812 gives the steps in the older names:

From the sidebar, go to Project settings → Issue types.
Select the work type, for example Bug.
Select Description and write the default description you want people to see when they create a work item of that type.
Save the changes.

On a current site the same place is called Space settings → Work types: next to the space’s name in the sidebar, select •••, then Space settings, then Work types (Set up work types). That page says you need the Administrator role, with the Administer spaces permission, to change work types.

Limits

No tables. Atlassian’s KB on tables says you cannot add a table to a team-managed default description. Its workarounds are an Automation rule that writes the table after creation, or a custom Paragraph field shown on the Create screen instead of Description.
One text per work type. People cannot choose between a short and a long bug report. If two kinds of bug need different questions, you need two work types or a different approach.
Description only. The default description does not set labels, priority or a checklist with it.
One space at a time. Atlassian’s fields page says a team-managed space’s fields are not shared with other spaces. Ten team-managed spaces mean ten copies of the text to keep in step.

Company-managed spaces: no default for Description

The request, and where it stands

In a company-managed space, Jira does not support a default value for the system Description field. Atlassian’s KB says so plainly. The request for default values on system fields, JRACLOUD-4812, was opened in October 2004. On 21 October 2026 it was marked Future Consideration, unresolved, with 2,799 votes.

Atlassian’s updates on the request tell the story. In November 2022 it planned field contexts for Priority and Description, with Description first. In April 2023 it wrote that the work had been paused after a change of priorities. A narrower request for a default description template, JRACLOUD-42197, was closed as Won’t Do in August 2024.

Atlassian’s workaround: a stand-in field

The KB gets a similar result with a custom field that can have a default, copied into Description when the work item is created:

Create a custom field of type Paragraph, for example TemplateDescription.
Add it to the space’s Create screen only. The view and edit screens keep the system Description field. If one screen serves all three, make a separate Create screen.
On the field, choose ••• → Contexts and default value, then Edit Default Value, and enter your template.
Remove the system Description field from the Create screen.
In the workflow, open the Create transition and its Post Functions. Add two at the top: Copy Value From Other Field, from TemplateDescription to Description on the same work item, and then Update Work Item Custom Field to clear TemplateDescription. The copy must run before the clear.
Publish the workflow.

What it costs you

Three kinds of configuration. A custom field, a screen and a workflow, for each work type that needs its own template. Plan it with whoever looks after them, because other spaces may share the same screen or workflow.
Order matters. If the clear runs before the copy, the description ends up empty. The KB warns about this.
The field must stay off other screens. If it shows on the view or edit screen, people see a second, confusing description field.
Still one template per work type. The default value is a single text, not a choice.

The KB calls this a similar result, not a native default description. If you can live with seeing the template only after creation, the Automation rule below changes less.

An Automation rule: write the template after creation

Atlassian’s KB for a default description template works in both kinds of space:

Trigger: Work item created.
Condition: Work item fields condition, where the work type equals the one you want, for example Story.
Action: Edit work item, setting Description. The KB’s value starts with {{issue.description}}, which keeps whatever the person typed, then a dividing line, then the template. Leave the smart value out and the template replaces what they typed.

The KB builds it under Project settings → Automation with Create rule. The rule must be turned on. Atlassian’s permissions page says rules for one space are managed by its admins, and rules across Jira by people with the Administer Jira permission.

What that means in practice

Nobody sees it while creating. The KB says the description is updated after the work item is created. The person in the Create dialog starts from an empty description, and the headings arrive afterwards, so they are not prompted for the steps to reproduce while they still remember them.
It counts towards your Automation usage. Atlassian’s usage page says every trigger, condition, action, branch and loop that runs counts as a step, from a monthly allowance that depends on your plan. A rule on Work item created runs for every new work item in its scope, including those its condition then turns away. Our step billing guide has the arithmetic.
Tables work here. The table KB above uses this kind of rule to put a table into the description.
Still one text per rule or condition. Several templates mean several conditions, and the rule has to tell the cases apart by something it can see on the new work item.

For a block of text that someone inserts by hand while writing, see block templates in the hub guide.

Description templates to copy

Short versions to paste into a default description, a stand-in field or an Automation action. The template pages have longer versions, with a note on what each section is for, and the generator lets you change them.

Task

What needs doing
[The work, and what is different when it is done.]

Why
[The reason, or the request it comes from.]

Done when
- [What must be true when this is done]
- Whoever asked for it has been told

Full version: Jira task template.

Bug

Steps to reproduce
1. Go to [page or screen]
2. [Do this]
3. [Then this]

Expected result
[What should have happened]

Actual result
[What happened instead. Copy any error message exactly.]

Environment
Version or build, browser or device, operating system

Full version: Jira bug report template.

User story

User story
As a [type of user], I want [goal] so that [reason].

Acceptance criteria
- Given [context], when [action], then [result]
- Given [context], when [action], then [result]

Out of scope
- [What this story does not include]

Full version: Jira user story template.

Epic

Goal
[The outcome in one or two sentences.]

Problem
[What is wrong today, and why it matters now.]

Scope
- In: [what is included]
- Out: [what is not]

How we will know it worked
[A measure, and the number to reach if there is one.]

Full version: Jira epic template.

Keep a default short. People delete headings they do not need, and a long default teaches them to delete all of it.

Templates people pick: what our app does

We make Issue Templates & Create Defaults for Jira. That is why this page exists. This section describes the app as its documentation stands on 21 October 2026.

What it does

A Templates page in each project. People pick a template there, and Jira’s own Create dialog opens with the template filled in: summary, description with a checklist (as Jira’s own action items), labels and priority, and, where the template sets them, the assignee (the person using the template), a due date and components. The person can change anything before creating, and Jira’s required fields, permissions and workflow apply. (docs)
Several templates per work type. A support-found bug and a test-found bug can have different templates, side by side on the same page.
A default template per work type. When someone opens Create from the Create button or with C and chooses that work type, Jira’s Create dialog names the default under Summary: Default template for this work type: “Bug report”. To use it, open Templates in the project sidebar. (docs)

What it does not do

It does not fill the Create dialog by itself, and it does not give the Description field, or any other field, a default value. Someone who opens Create from the Create button starts from Jira’s usual empty form, with one line naming the default template. So the app does not do what JRACLOUD-4812 asks for. If you need text in Description the moment the dialog opens, the native options above are the ones that do that.

Why not? Since version 2.6.0 (21 October 2026) the app leaves the form alone. Jira can run an app again on a Create dialog that was minimised and restored, and report an empty form while the person’s text is still on screen. An app that filled empty forms could then overwrite what they had typed. Until Jira tells apps which form they are on, ours names the default and writes nothing.

It does not apply to inline create on a board or list, email, Automation, the REST API, import or cloning.
Service projects are not on Atlassian’s supported list for the Create dialog feature it uses.

The full list is in the documentation’s limits. The app suits teams that want people to choose between several templates, each setting more than the description. It is not a replacement for a native default.

Marketplace Documentation

Which one to use

The options on this page, from the Atlassian pages linked above, checked 21 October 2026.

Approach	Where it applies	Seen while creating?	Who maintains it	Limits
Team-managed default description	Team-managed spaces, per work type	Yes	Space admins (Administer spaces)	One text per work type; no tables; description only; one space at a time
Stand-in Paragraph field and post functions	Company-managed spaces	Yes, in the stand-in field	Whoever looks after custom fields, screens and workflows	One default per field; post-function order matters; field must stay off view and edit screens
Automation: Work item created, Edit work item	Either kind of space	No, it is written after creation	Space admins for space rules, Jira admins for global rules	Runs on every new work item in scope; counts towards Automation usage; one text per condition
Our app: a template picked on the Templates page	Company-managed and team-managed software and business projects	Yes, when opened from the Templates page; from the Create button, only the default’s name	Project admins for their project, Jira admins for all	No default value for any field; not inline create, email, Automation or the API; not service projects

Our plain advice: if each work type needs one fixed description, use the native default in a team-managed space, or the stand-in field in a company-managed one if you can change its screens and workflow. Use Automation when changing screens is not an option and a template that appears after creation is good enough. Consider an app when people need to choose between several templates, or a template has to set more than the description.

Questions

Can I set a default description in Jira Cloud?

In a team-managed space, yes: one default description per work type, set by a space admin. In a company-managed space, not for the system Description field. Atlassian’s workaround puts a custom Paragraph field with a default value on the Create screen and copies it into Description with workflow post functions.

Is Atlassian adding default values for the Description field?

The request, JRACLOUD-4812, was opened in 2004 and was marked Future Consideration on 21 October 2026. Atlassian’s April 2023 update on it says the work was paused. A narrower request for a default description template, JRACLOUD-42197, was closed as Won’t Do in August 2024.

Will an Automation rule show the template while someone creates the work item?

No. A rule on Work item created runs after the work item exists, so the person creating it sees an empty description and the template appears afterwards. Each run also counts towards your Automation usage.

Can a default description contain a table?

Not in a team-managed default description, according to Atlassian’s knowledge base. It suggests an Automation rule that writes the table into Description after creation, or a custom Paragraph field used on the Create screen instead.

Does the Issue Templates app give the Description field a default value?

No. It does not set default values for fields and does not fill the Create dialog by itself, so it does not do what JRACLOUD-4812 asks for. People pick a template on a project’s Templates page, and Jira’s own Create dialog opens with that template filled in. For a work type with a default template, the Create dialog names it under Summary.

Guides in this series

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 children under every epic or work item.
Jira default description: this page.
Jira employee onboarding template with sub-tasks: the same steps for every new starter.

Also useful:

Jira issue template generator: free text for a bug, story, task, incident, spike or epic.
Default templates in the Create dialog: how the app names a default, in its documentation.
Recurring tickets in Jira Service Management after Automation step billing: what Automation steps cost.

Sources and changes

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.

JRACLOUD-4812: Default values of system fields (Future Consideration) (checked 21 Oct 2026; 2,799 votes that day)
JRACLOUD-42197: Ability to set a default description template (Closed, Won’t Do) (checked 21 Oct 2026)
Set Default Description in Jira Cloud Company-Managed Projects (KB) (checked 21 Oct 2026, last changed 26 Sep 2025)
How to Add Tables in Jira Default Description (KB) (checked 21 Oct 2026, last changed 25 Sep 2025)
Set Default Description Template for Jira Cloud Work Item Types (KB) (checked 21 Oct 2026, last changed 25 Sep 2025)
Set up work types in team-managed spaces (checked 21 Oct 2026)
Customize work item fields in team-managed spaces (checked 21 Oct 2026)
Jira automation triggers (checked 21 Oct 2026)
Jira automation actions (checked 21 Oct 2026)
How is your automation usage calculated (checked 21 Oct 2026)
Permissions required to manage automation flows (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.