keelapps/Prefill/Documentation

Documentation

Prefill adds one thing to Jira: a link that opens a short request form instead of a create screen. Everything below is either how to build that form, or which of Jira's own rules still apply once somebody uses it — and they all do.

What Prefill is, and is not

Prefill is an intake link. Its product is the entry point: a URL you paste into Slack, an email signature, a runbook or a monitoring alert, which opens a page a colleague can complete without ever seeing Jira's create dialog.

It is not an issue-template app. Templates prefill Jira's own create screen; the submitter still has to know their way around it. Prefill replaces the screen for that one request rather than pre-typing it.

It is not an anonymous or external portal. Submitters are your own Jira users — signed in, with permission to create issues in the target project — and every issue is created as the person who submitted it. The scenario it is built for is “the whole company has a Jira seat, but only a handful of people know how to file a ticket”. For requests from people without a seat, Jira's own forms can be shared with anyone who has the link (if your admin allows public forms), and Jira Service Management runs customer portals, whose request types can already hide preset values and prefill from the portal link.

Where Prefill lives

• Apps → Request forms — the library. Build forms, copy their links, and see what each one has produced. This page is also what a shared link opens.
• Project → Request forms — the forms that file into this project, for the people who own its queue.
• Apps administration → Prefill for Jira — every form on the site with a live health verdict, for Jira administrators.

There are no queues and no scheduled jobs. A form is stored configuration; a submission is one API call to Jira.

Building a form

1. Name it, and describe it for whoever finds it later.
2. Pick a project and issue type. Sub-task types are excluded, because a sub-task needs a parent that an intake link cannot supply.
3. Decide what each field does — fixed, hidden or asked. See below.
4. Save. The form is checked against Jira's live create screen at this point, and refused if it could not create an issue.

Fixed, hidden and asked

Every field on the create screen is in one of three states:

Hidden values never reach a submitter's browser. They are applied server-side, so a form pinning Priority to High cannot be talked out of it by anyone reading the page source.

The routing fields — project, issue type, component, labels, the custom field your automation keys off — are the ones worth fixing. What is left to ask is usually two or three things only the submitter knows.

Sharing the link

Each form has one key. Appending that key to the app page's URL as a query parameter opens that form directly. Each form's page (Manage forms, then Details) gives you the full link to copy, and saving a form takes you straight there.

Deep linking was verified on a development install on 9 September 2026 and on a production install on 26 September 2026: the key opens its form, and an unknown key renders the app's own “that form does not exist” page rather than an error. It relies on Jira passing the link's query string to the app, so when a link arrives without a usable key, Prefill falls back to a form picker: the visitor chooses from the forms they can use and continues.

One practical note if you administer the app: the app page's URL contains an environment identifier, so a link generated from a development installation will not open on a production one. Copy links from the installation your colleagues actually use.

What the submitter sees

A short page: the form's name and description, a badge showing which project and issue type the request will become, and only the fields you marked as asked, with their defaults filled in.

Submitting creates the issue through Jira's own create API, executed as the person submitting. That means:

• The reporter and creator are the real submitter, not the app and not you.
• Jira's own permissions decide whether the issue can be created at all.
• Jira's notifications and automation rules for issue creation fire as they do for any new issue.

Prefill cannot create an issue on behalf of somebody who could not have created it themselves.

Who can submit

Signed-in Jira users with permission to create issues in the target project. That is the whole answer, and it is not a setting: Prefill creates every issue as the person submitting it, so there is no anonymous mode to switch on.

If a form is opened by somebody who cannot create issues in its project, Jira refuses the creation and the form says so. The right fix is a Jira permission change, not an app setting.

Who can build and manage forms

A Jira administrator picks the rule on the admin page, and it applies to every form action — creating, editing, retiring, deleting, and seeing a form's own page with its hidden values, counts and recent issues:

• Project administrators (the default) of the project the form files into.
• Anyone who can create issues in that project.
• Jira administrators only.

Jira administrators qualify under every rule. The check is made against the project the form files into as saved, so moving a form to another project needs the right in both. While a subscription is inactive, creating and editing forms is paused; existing forms keep accepting submissions.

URL parameters

An external system — a monitoring alert, an internal tool — can carry context into a form by adding parameters to the link, so the summary or an environment field arrives already populated.

Two rules, both enforced on the server:

• Opt-in per field. Only fields whose owner explicitly allowed URL population can be set this way. Every other parameter is ignored.
• Never a hidden field. A fixed, hidden value cannot be overridden by a URL.

Validation

Forms are checked three times, and the first one is the one that matters:

• When you save. Prefill reads Jira's live create screen for that project and issue type. If a required field is neither filled by the form nor asked of the submitter, the save is refused — while the person who can fix it is still looking at it. A broken intake link is otherwise discovered by a colleague whose request silently failed to file.
• When it is opened. Create screens change: fields get added, options get retired, projects get reconfigured. A form that could no longer file an issue stops before anyone fills it in, and its page tells you why.
• On submission. Jira has the last word. If it refuses a value the submitter typed, the field is marked; if it refuses one of the form's hidden values, the submitter is told the form's owner has to fix it, and the form's page shows you Jira's reason with the date.

The admin page carries the same verdict for every form on the site, so an administrator can see the ones that need attention without opening each one.

Custom field types

Field shapes are read from Jira's own create metadata — never guessed from a field name. Supported: select, multi-select, cascading select, user, group, date, datetime, number, labels, time tracking and rich text, alongside the standard system fields. Date-and-time fields get a date picker and a time picker, and are read in the submitter's own time zone.

A field type Prefill cannot fill honestly is reported as unsupported in the builder, where you can choose something else — rather than accepted and then failing at submission time in front of a colleague.

Use counts and recent issues

Each form records how many times it was opened, how many times it was submitted, and when it was last used. Those counts are approximate by design — they are kept in sharded counters so that concurrent submissions never block one another — and they are there to answer one question: is this link being opened and then abandoned?

Alongside them, the last issues the form produced. Only the issue keys are stored; the summary and status shown next to them are read from Jira live, each time you look, and an issue you cannot read in Jira is not listed. Pressing Submit twice files one issue: the second press gets the issue the first one created.

Retiring a form

Retiring a form stops it accepting submissions but keeps its key reserved. Anyone still holding the old link — in a bookmark, a wiki page, a six-month-old Slack message — is told the form was retired, instead of meeting a dead page or, worse, a different form that later claimed the same key.

A retired form can then be deleted from its page, after a confirmation. Deleting removes its definition, its counters and its recent-issue list, and frees its key for a new form. Issues it already created are ordinary Jira issues and are unaffected.

Permissions the app requests

There is no permissions.external block: the app cannot make an outbound call even if it tried to, which Atlassian enforces at the platform level.

Not in this release

• Anonymous or external submission. Not a roadmap item: Prefill files every issue as a signed-in Jira user.
• Issue templates for Jira's own create screen.
• Sub-task creation, which needs a parent an intake link cannot supply.
• Attachments on submission.
• Editing existing issues. Prefill creates; it does not update.
• Approval or routing workflows after creation — that is Jira automation's job.

Support

Questions, bug reports and feature requests: raise a support request. Security issues: report privately.