JRACLOUD-4812 asks for default values on system fields. It was opened in 2004, it has 2,798 votes, and it is still open. The request is not exotic: a team wants every bug in their project to start with Priority set to Medium, the right component selected, and a description skeleton already in the box, so the person filing it fills in what is actually specific to their bug instead of re-deciding six fields that are identical every time.
Every admin who has tried to improve issue quality has wanted this, and every one of them has found the same thing. This post covers what Jira Cloud genuinely gives you, the workaround most teams land on and the exact point it stops being good enough, and the API that does the job properly.
What Jira Cloud actually offers
- Defaults exist for some custom field types. A select list can carry a default option in its field configuration. That covers a slice of the problem and none of the system fields the request is about.
- There is no native issue template. No "create from template" anywhere in the product.
- There is no recurring issue. Work that happens every week is created by hand, or forgotten.
The Automation workaround, and its ceiling
The standard answer is a rule that fires after creation:
When: issue created → If: project = Payments AND type = Bug → Then: edit issue, set Priority = Medium, Component = API.
This works. For one project and three fields it is the right answer and costs nothing. Three things end it:
- It happens after the fact. The person filing the issue still stares at an empty form. The values appear a second later. The part that actually improves issue quality, a description skeleton in front of someone while they are typing, is exactly the part a post-creation rule cannot do.
- Every issue carries an automation edit. Your history gains a machine edit on every single issue, which is noise in precisely the audit trail you wanted to keep clean.
- It consumes execution budget. On a busy site, field defaulting quietly becomes a meaningful share of your monthly automation limit.
The mechanism that does it properly
Jira does expose the right hook, but only to apps: jira:uiModifications can set
field values on the Global Issue Create screen before anyone types. That is how the
native behaviour would be built if it were built, and it is the difference between a form that
opens pre-filled and a form that gets corrected behind you.
The honest limit, which matters when you evaluate anything in this category: the UI modifications API covers a defined set of field types. Anything outside it cannot be pre-filled. A tool that silently drops those fields is worse than one that refuses them, because you find out months later when someone notices the default never applied.
Templates and recurrence are the same complaint
Teams that want defaults almost always want two neighbours of it. Templates, because the description skeleton is really a saved issue with subtasks. And recurring issues, because the weekly access review is the same issue every week. Both get approximated with a cloned "template issue" that then shows up in every board and report, or with one Automation rule per recurring thing.
The app
Issue Templates, Defaults and Recurring for Jira does the three together. Templates of fields and subtasks, applied to an existing issue or used to create a new one. Create-screen defaults per project and issue type through the UI modifications API, with unsupported field types reported when you save the rule rather than dropped. Recurring schedules on a daily, weekly or monthly cadence.
One design decision worth stating because it affects your audit trail: when a person applies a template, the write runs as that person, with their permissions and their name in the issue history. Only recurring creation runs as the app, because no person is present. An app that does everything as itself is easier to build and makes your history useless.
Runs entirely on Atlassian Forge, inside your own site. App details and screenshots.
Written by Abaho Katabarwa at Katabarwa Labs. We build small, single-purpose Atlassian and Azure tools that run entirely inside your own tenant. Questions: support@katabarwalabs.dev.