How to pre-fill fields on the Jira Create screen

To pre-fill the Jira Create screen, Jira’s own tools only get you partway: set a default value per custom field (under Custom fields, each field’s Contexts and default value), scoped to a project or issue type. Each field’s default is configured on its own — there’s no native way to set priority, component, labels and a custom field together as one coordinated set for “production incident,” and the system Description field can’t have a default value at all. The rest of the gap is filled by a template app, which pre-fills the real Create screen — every field, Description included — from a definition you choose, while keeping it all editable before submit.

Every team has a shape its issues are supposed to take — a bug always needs a priority, a component and a “steps to reproduce” field; a support task always carries the same label and a customer field. And every team watches those get skipped, because the person creating the issue fills a blank Create screen from memory and is in a hurry. Here is how to make the Create screen start filled in instead of blank.

What Jira does natively

Jira has defaults, but shallow and field-by-field ones:

• Field defaults, set per context. A custom field can carry a default value, scoped to a context — one or more projects or issue types. But each field’s default is configured separately; there is no single place to set a coordinated group of values (priority, component, labels, a custom field) for one kind of work.
• The system Description field can’t default at all. Atlassian’s own help documentation is direct about this: adding a default value to the native Description field isn’t supported. The documented workaround is to build a separate custom field, hide the real Description field on the Create screen, set a workflow post-function to copy one into the other — admin work most teams never get to.
• Project and issue-type context changes which fields show, not their values. Field configurations and screens vary by project and issue type, so different work shows different fields — but the values still start empty.

What Jira does not give you is a way to say “when someone creates a production incident, start the screen with this priority, this component, these labels, this description, and these custom-field values — together.” The result is predictable: issues created with required fields blank, inconsistent labels, and a lot of after-the-fact cleanup.

The fix: pre-fill the real Create screen from a template

Prefab pre-fills Jira’s native Create screen from a template you choose — summary, priority, labels, components, dates, assignee and most custom fields, including required ones. Because it drives the Create dialog your team already uses, there is no separate form to learn and every value stays editable before submit.

Why that matters:

• Issues start correct. The fields that always get skipped are already set, so the required ones are not blank and the labels are not improvised.
• Consistency without policing. Instead of reminding people what to fill in, the right defaults just appear for that issue type or project.
• Speed with control. It is a head start, not a straitjacket — anyone can change a pre-filled value before they create the issue.
• It pairs with structure. Pre-filled fields and reusable issue templates are the same idea; when you need the parent-and-children too, the template scaffolds the whole hierarchy with fields filled at every level.

A quick way to start

Pick one issue type that causes the most cleanup — incidents, customer bugs, release tasks. Write down the fields your team sets the same way every time, save them as a template for that type, and let the Create screen start pre-filled. You will feel the difference on the very next issue, and you can copy the pattern to the next type from there. If you often start from an existing issue instead, duplicating a Jira issue is the related move.

The takeaway

Jira’s native defaults stop at single-field values, which is why required fields keep slipping through. Pre-filling the Create screen from a per-type template turns “fill in the blanks from memory” into “check and submit” — issues start consistent and complete, and nobody has to learn a new screen to get there.