Field Defaults

Default values for Jira's Create dialog. Pick a project, optionally an issue type, and the values people should start with. Field Defaults fills them in the moment someone opens Create, so every new issue starts with the right template, labels, priority, assignee and dates.

Getting started

1. Install Field Defaults from the Atlassian Marketplace.
2. Open Jira settings → Apps → Field Defaults (or Manage apps, then Configure next to Field Defaults) and click New rule.
3. Choose a project and, if you want, one issue type. Leave issue type on "All issue types" to cover the whole project.
4. Add the fields you want filled in and their values, then save. The next Create dialog opened in that project uses them. No page reload or screen changes needed.

Fields you can set

Relative dates and times use the time zone in the person's Jira profile. Jira's own limits apply: 255 characters for Summary, text fields and each label, 32,767 for Description and paragraph fields, and up to 90 different people filled in at once.

Options for each field

• Only if empty (the default) fills a field that has no value yet. Priority and Reporter are the exception: Jira always fills them in itself, so your default replaces Jira's starting value (the project's default priority, and the person creating the issue).
• Always also replaces a default value Jira fills in by itself, such as a select field's default option.
• Either way, a value someone types or picks is kept. If someone changes a field back to the value Jira starts it with, it counts as not filled in.
• Lock makes the field read-only in the Create dialog once it has a value. Together with Always, a locked field always gets your value. An empty field is never locked, and if Jira turns a value down (for example an option deleted since the rule was saved) or another app fills in the same field at the same time, the field is unlocked again as soon as someone edits the form, so a required field can't get stuck. A lock only applies in the Create dialog: the value can be changed after the issue is created.

Each issue type can offer different options for the same field. A rule for the whole project can only use options that every issue type with that field offers; for the others, set the field in a rule for each issue type.

When several rules apply

A rule for a project and one issue type beats a rule for the whole project, field by field. For example, a project rule can set labels for everything while a Bug rule sets the description template and priority for bugs only. Two rules for the same issues can't both fill in the same field.

If two admins change rules at the same moment, one change waits a moment for the other. If someone changed a rule after you opened it, Field Defaults asks you to open it again so you don't undo their change.

Changing project or issue type in the dialog

When someone switches issue type in the Create dialog, values Field Defaults filled in are swapped for the new type's defaults. If the new type has no default for a field, the value goes back to what Jira starts it with: empty, Automatic for Assignee, the project's default for Priority. Anything the person typed or picked themselves stays.

Switching to another project with rules works the same way: the first project's values and locks are taken out and the new project's defaults fill in. A project without rules is left as it is, because Field Defaults doesn't run there.

After Create another, fields Jira clears for the next issue get their defaults again, and changes the person made that Jira carries over stay.

To tell its own values from what people pick, Field Defaults keeps a short note of what it filled in, in the browser tab's session storage, which the browser deletes when the tab is closed. If a browser doesn't allow that storage, Field Defaults compares values with your rules instead. Then a value someone picks that happens to match another issue type's default can be swapped too, and values from another project stay.

Project leads

Defaults that use the project lead follow the project: when the lead changes in Jira, the rules pick up the new lead automatically. A change made while the app isn't licensed is picked up when you click Re-apply all rules.

Turning rules off, and repairs

Use the toggle in the rules table to pause a rule without losing it. Deleting a rule removes it from Jira straight away. If a rule stops working after changes to a project, its issue types or a field's options, click Re-apply all rules. It rewrites every rule to Jira, removes leftovers and lists any rule that needs editing, for example because its project was deleted or an option it fills in no longer exists.

A project can have up to 100 rules and a site up to 500.

Where defaults apply, and where they don't

Field Defaults uses Atlassian's UI modifications feature for the Create dialog. This means:

• Defaults apply in Jira's Create dialog on the web: the Create button at the top of every page and the c shortcut.
• Add a child issue and Create subtask on an issue only open that dialog when the child issue type has at least one required field besides Summary. Otherwise Jira creates the issue inline and no defaults apply.
• They don't apply to quick create on boards, backlogs and lists, the Jira mobile apps, issues created by email, automation, imports or the REST API.
• Software and business (Jira Work Management) projects, company-managed and team-managed, are supported. Service and Product Discovery projects are not.
• The Sprint, Team, Parent, Security level and app-provided fields can't be set this way, so they don't appear in the field list.
• Jira allows up to five apps that change the Create dialog per project and issue type. If another app also changes the same field, the last one to run wins.