Create and link

Sometimes the work item somebody wants to link does not exist yet. Instead of leaving the form, creating it in the other space and coming back, people can create it right in the picker: they type a name, click one entry, and the new work item is created and taken into the field. An admin decides per context whether this is offered at all and where the new work items land.

Switching it on

The setting lives in the Picker section of the field's context configuration, see the Configuration reference. It is off by default.

Switch on “Allow creating new work items from the picker” in the context you want it in. Every context of the field decides for itself, so a space where new items should never appear simply leaves it off.
Choose the space for new work items. This is the space the created work items land in, typically the same space the picker's JQL filter points at.
Choose the work type for new work items. The list holds the work types this space can create, subtasks excluded, because a subtask would need a parent that the picker cannot supply.

Do not point it at a service desk space. A work item created from the picker carries no request type, because the picker has no way to ask for one. In a Jira Service Management space that means it never appears in the customer portal and ends up among the leftovers in a queue, visible to agents but attached to no request type. The Check your setup card says so as soon as you pick such a space. Create into an ordinary business or software space instead, and let the service desk keep raising its own requests.

Both answers are needed. As long as the space or the work type is missing, the configuration page says so (“Pick a space and a work type. Until then the picker offers no create option.”) and the picker behaves as if the feature were off. There is no half-configured state that fails later at the user's expense.

What people see in the picker

With the feature on, the entry Create “…” appears in the suggestion list as soon as someone types, carrying the text they typed. It sits at the top of the list, above the matches, so it stays visible even when the search already found a screenful of work items.

One click and Linker creates the work item with the typed text as its summary, in the configured space and work type. A flag confirms it: “<KEY> created”, with the note that the item is selected in the field and gets linked when the field is saved, plus a button that opens the new work item.

The entry is deliberately absent in three situations:

While the results are still loading, so nobody creates a duplicate of a match that was about to appear.
While the picker recognises a pasted list of work item keys: there the intent is to add existing items, not to create one named after a list of keys. See the bulk paste in the FAQ.
In the service desk portal, always. See Never in the portal below.

Who creates the work item

The new work item is created in the name of the person picking, not in the name of the app, whatever the context's Permission model says for searching. That has two consequences worth knowing:

They need Jira's Create Issues permission in the target space. Without it, Jira refuses and the picker says so; nothing is created.
They become the reporter of the new work item, and it shows up in the space's history under their name, exactly like an item created through Jira's own form.

Linker sets three things and nothing else: the space, the work type and the summary (cut at 255 characters). Everything else stays at whatever the space's workflow and field configuration produce, so a work item created this way is an ordinary work item that anyone can complete afterwards.

When the target work type has required fields

This is the case to plan for. Because Linker sends only space, work type and summary, a work type whose create screen demands another field cannot be created this way: Jira rejects the request, and Linker does not guess a value, does not silently drop the requirement and does not open Jira's create screen instead.

What the person sees is an error flag “Creating failed” that stays on screen until it is dismissed and carries Jira's own message, naming the fields it is missing. Nothing was created and nothing was added to the field, so the picker is exactly where it was.

A required field only blocks when it has no default value. Jira's own required fields that Linker already covers, summary, space, work type and reporter, never block.

You are told before your users are. The field configuration checks the create target while you set it up: when the chosen work type demands fields the picker cannot fill, the Check your setup card lists those fields by name and says that creating from the picker would fail with Jira's error. So the normal way to meet this is while choosing the work type, not through a support ticket from somebody who tried. See Check your setup.

Three ways out, in the order we would try them:

Give the field a default value in the space's field configuration. The requirement stays, Jira fills it, and creating from the picker works.
Make the field optional on that work type, if the requirement was there to guide the create form rather than to guarantee data.
Point at another work type whose create screen asks for less, for example a lightweight type meant exactly for quickly captured items.

If none of those fit, leave the feature off for that context. People then create the work item in Jira and pick it in the picker afterwards, which is the behaviour they had before.

How the new work item becomes a link

Creating and linking are two steps, and it is worth knowing which is which:

The work item is created immediately, the moment the entry is clicked. It exists in Jira from that second, with its own key.
It is selected in the field, following the context's Selection setting: in a single-selection context it replaces the current value, in a multi context it is added to the list.
The native link is created when the field is saved, on the instant path like any other pick. See How linking works.

On the create screen, the link follows a little later. When somebody uses the picker while creating a work item, there is no work item to link from yet. The new item is created and kept in the field, and the link is made once the work item itself is saved, through the safety net, normally within a few minutes. See Limitations & timing.

If a link cannot be written right away, the picker says so instead of pretending, and the safety net catches up on its own.

Never in the portal

In the Jira Service Management customer portal the create entry is never offered, no matter how the context is configured. Customers pick from what the JQL filter allows; they do not create work items in your internal spaces. The picker hides the entry there, and the app refuses the request a second time on the server, so the boundary holds even if someone calls the endpoint directly. See Service desk portal.

When the entry does not show up

Cause	What to check
The toggle is off for this context	A field can have several contexts, and a space-specific context wins over the global one. Configure the context that actually applies to the space.
Space or work type not chosen	The configuration page shows the hint below the selects.
The create target no longer exists	Space archived, work type removed from the space: the Check your setup card reports it.
The app's licence is not active	Creating is one of the paths a lapsed licence blocks. See Troubleshooting & FAQ.
You are in the service desk portal	Expected, see above.
Nothing is typed yet	The entry carries the typed text, so it appears with the first character.

Watch the picker's own filter. If the create target is a space the picker's JQL filter excludes, the work item is created and selected, but the picker would never have suggested it. That is usually a mistake in the setup rather than an intention, so the Check your setup card names it: widen the filter, or create into a space the filter covers.