Overview and setup

What the toolkit adds, how to create one of its fields, and where the settings live.

What it is. Three new custom field types, one workflow validator, and a way to hand select list options over to project administrators.

If terms like custom field, field context or screen are unfamiliar, read Jira words used in these guides first. This page assumes them.

What you get

Feature	What it is for
Issue Picker	A field whose options are the results of a JQL query. Users pick one issue or several, and the app can create real Jira issue links for each selection.
Checklist	One or more checklists on an issue, with per-item statuses, descriptions, due dates, mandatory flags and assignees. Progress is searchable in JQL.
Masked Input	A text field that formats while the user types and refuses values that do not match the format. 19 ready-made presets.
Checklist Completion Validator	A workflow validator that blocks a transition while checklist items are still open. Covered on the Checklist page.
Select list options	Lets a project administrator add, edit, reorder and retire the options of their own select field, without giving them Jira administration rights.

What you need first

Jira Cloud. Works with Jira Software, Jira Work Management and Jira Service Management.
Jira administrator rights to create fields, edit their configuration and edit workflows.
Project administrator rights are enough to manage delegated select list options, once a Jira admin has enabled the field.

Create one of the fields

1Install the app.
2Go to Jira → Settings → Issues → Custom fields and click Create field.
3Choose Issue Picker, Checklist or Masked Input. They appear in the list alongside Jira's own field types.
4Name the field and associate it with the screens where it should appear. A field that is not on a screen is invisible, and this is the most common reason people think the app is not working.
5Open the field's Contexts and click Edit configuration. Every setting described in these guides lives there.

Configuration is per context, and this matters

A field context is the field's settings for a specific set of projects and issue types. The same Checklist field can require all items in one project and nothing in another. If a field behaves differently than you expect, check which context covers that project first.

Where each screen lives

Screen	Where	Who
Field configuration	Settings → Issues → Custom fields → your field → Contexts → Edit configuration	Jira administrator
Select List Option Management	Jira → Apps → Custom Fields Toolkit	Jira administrator
Select List Options	Project settings → Select List Options	Project administrator
The Checklist Completion Validator	Settings → Issues → Workflows → transition → Validators	Jira administrator

Where the fields appear

All three field types are declared for the issue view, the create screen, transition screens, and the Jira Service Management customer portal — both for a customer filling in a request and for reading one back. A checklist on a portal request form works the same way it does on an issue.

One place they fall back to Jira's plain editor

On surfaces Jira renders itself — boards, the issue navigator, bulk edit — an app field can get Jira's default editor for its underlying data type rather than the app's. The Checklist field guards that case with a rule that every line must be a checklist item, a description line or the meta line, so free-typed text is refused rather than saved and silently dropped. Masked Input can only guard a length there, because the mask lives in per-context configuration and no static rule can see it. Edit these fields on the issue view and the real editors apply.

Where the data lives

Field values — selected issues, checklist items, masked text — are stored by Jira as ordinary custom field values on the issue. So is every field's configuration: the JQL query, the checklist settings, the mask pattern all live in Jira's own field-context configuration, which is why they travel with a field export and follow the field's own permissions.

The app's own storage holds one value: the list of which field contexts are delegated to project administrators. That is the whole of it. See the privacy policy.

What happens without an app licence

Your fields keep working. The three field types render, edit and save exactly as before, on every issue and every portal request. That is deliberate: a licence lapse should cost the customer new configuration, not the contents of their issues, and blanking a field out would break a transition somebody is halfway through.

Still works	Stops until the licence is active
Viewing and editing all three field types on issues, create screens, transition screens and the portal.	Adding, editing, reordering and deleting select list options — the four writes behind the delegation feature.
Reading fields, contexts and the options already configured; changing which contexts are delegated.	Creating issue links for a picker value set on the create screen. Links made by editing an existing issue still work — it is the background trigger that is gated.
Values already stored on your issues, untouched.	Refreshing the `Checklist-` values that JQL searches.** Existing values stay; they stop being updated when a checklist changes.

Both admin screens show a warning — “No active licence” — saying which of the above applies, and the option buttons carry a Needs an active licence note. A site administrator can start a trial or renew from the Atlassian Marketplace.