System Field Defaults for Jira

Documentation · System Field Defaults for Jira · Last updated 12 September 2026

What it does: System Field Defaults fills system fields on newly created Jira issues — no matter where the issue was created. Configure a rule per project × issue type; when an issue of that type is created, the app applies your defaults within a second or two.

Why it works everywhere

Atlassian's UI modification entry points do not cover every way an issue can be created — issues created from a backlog row, from an automation rule, by email or through the REST API never reach a create-screen hook. This app does not rely on UI hooks at all. It listens to the avi:jira:created:issue product event, which fires for every creation path:

backlog and board inline create
the global Create button and the c keyboard shortcut
REST API and Forge/Connect app integrations
email requests and Jira automation rules

The trade-off is timing: defaults appear a second or two after the issue exists, rather than being pre-filled in the create dialog. In exchange they work on every path, including ones a UI hook cannot reach.

Choosing what to fill

For each project and issue type you can set:

Field	Behaviour
Priority	Set to a chosen priority level.
Labels	Added if not already present (case-insensitive).
Components	Added by name (case-insensitive).
Due date	Set to today plus a number of days. Only applied when the issue has no due date.
Assignee	Advanced: set to a specific account ID. Only applied when the issue is unassigned.

When a default is applied

Each rule has a mode. The recommended mode is only when the field was left untouched: the app compares the issue's value with the value the create screen would have pre-filled, and only then changes it. If a user deliberately chose a different value, the app leaves it alone.

For priority specifically: Jira stores a priority on every issue, so "untouched" cannot mean "empty". The app reads the pre-filled value from Jira's own create metadata and treats that value as untouched.

Untouched default (recommended) — user's explicit choices are never overridden.
Always override — the default wins even when the user chose something else. Use with care.
Labels and components are always additive: existing values are never removed.
If no rule exists for the project and issue type, the app does not modify the issue at all.

Seeing what happened

The app keeps a log of the most recent applications per project: the time, the issue key, which fields were applied and the result. It is visible on the same configuration page, so an administrator can confirm that defaults are working without reading logs elsewhere. The log holds the last 50 entries per project.

Setting it up

Open the app from Jira's Apps list (or from a project's settings, under Apps).
Choose the project and issue type.
Pick the fields you want filled and save.
Create an issue of that type — including from the backlog — and check the log.

The app needs only these scopes: read:jira-work, write:jira-work and storage:app. It writes only to issues covered by a rule you configured.

Limitations we want you to know

Defaults are applied after creation, not pre-filled in the create dialog. If you need pre-filling inside Jira's own create form, that is a different (platform-limited) approach and we do not claim it.
Custom fields are not supported in this version; system fields only.
Two Jira apps setting the same field on creation can conflict. If you already run another defaults app, disable one of them for the affected project.
Subtasks: rules are matched on the created issue's own issue type, so sub-task types need their own rule.