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, and it cannot become one. Submitters are your own Jira users — signed in, with permission to create issues in the target project. Anonymous intake requires an outbound connection to a vendor's server; Prefill declares no external network access at all, which Atlassian enforces at the platform level. 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, use Jira Service Management.

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, and the library page gives you the full link to copy.

Deep linking was verified working on the site we tested, on 9 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. We deliberately do not claim it for every Jira Cloud tenant — there are community reports of tenants where query strings are stripped before an app sees them. 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. That fallback is retained on purpose, not left in as dead code.

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.
• The issue appears in Jira's audit trail exactly as if it had been created through Jira's own interface, and notifications and automation fire normally.

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 a structural property rather than a setting: without an external server there is nowhere for an anonymous request to come from.

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.

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 twice, and the first time 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.
• On every submission. Create screens change: fields get added, options get retired, projects get reconfigured. So the check runs again at submission time, and a form that has gone stale reports what changed rather than throwing a raw API error.

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.

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.

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.

Deleting a form removes its definition, its counters and its recent-issue list. 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 — and which is also why anonymous submission is impossible here rather than merely unsupported.

Not in this release

• Anonymous or external submission. Not a roadmap item — it is incompatible with the app's zero-egress design.
• 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.