Service desk portal

In Jira Service Management, a Linker field can also work on the customer's side: customers pick a related work item while they raise a request, and they see what their request is linked to when they open it in the help center. What they get to see is deliberately narrow, and you decide all of it: whether the field is in the portal at all, which details it shows, and which work items it may offer.

A Linker field in the portal needs a JQL filter. Without one the field shows the customer nothing at all: no suggestions on the request form, no values on the request, and every pasted key rejected. That is deliberate and it is the first thing to set up, see Without a filter, the field stays empty. Inside Jira an empty filter still means every work item is allowed; only the portal fails closed.

What customers see

On a request in the portal, Linker renders one plain line per linked work item, built from the blocks you picked for the portal. Out of the box that is the summary alone, so a customer sees Lakeside Biotech and nothing else. Deliberately absent, because it belongs inside your company:

No work item keys. The line carries no key, and it is not a link, so nothing invites a customer to walk into Jira.
No status, assignee or priority, unless you add those blocks yourself.
No table. The columns, headers, avatars and lozenges of the agent view stay on the agent side.

At most ten work items are listed. When the request is linked to more, a closing line says how many are not shown, for example and 3 more. There is no Show more button in the portal: the point is to give customers the picture, not a browsable list. That line also counts entries your filter keeps out, so a customer learns only that the list is incomplete, never what was held back. A line whose blocks all come out empty is dropped instead of rendered blank, and when nothing is left the field reads None.

Agents are unaffected: on the work item itself, the same field still renders its full table with the columns you configured under Display. On a service desk request, Jira keeps custom fields in the collapsible Key details section of the agent view, so open that section to see the field there.

An empty field shows nothing at all. When the field has no value, Jira leaves it out of the customer's request completely: no label, no empty row, no placeholder. Customers only ever see the field when there is something to show.

Putting the field into the portal

Being on a screen is what makes a field visible to agents; in the portal, the request type decides. Until you add the field there, nothing of Linker appears in the help center, no matter how the field's context is configured.

Check the context: the field's context has to cover the service desk space, like for any other space.
Open Space settings → Request types and pick the request type customers use.
Add the Linker field to the request form and give it a question customers understand, for example Which of your sites is affected?.
Decide the portal blocks in the field configuration, see below, and try the result on a real request.

Two things Atlassian decides, not Linker. App fields on a request form always render at the bottom of the form, right above the send button, whatever position the form editor suggests; the order cannot be changed. And the request type configuration lists app fields under Hidden even while they work perfectly in the portal. Both are properties of Atlassian's Forge platform and affect every app field, not only Linker.

The blocks customers see

The field configuration has its own setting for this audience: Blocks shown in the customer portal, right below the suggestion row. It works like the other block editors: drag the blocks you want, drop the ones you do not, and a live preview shows a real work item as a customer would see it.

The blocks are the same six as everywhere in Linker, Key, Summary, Status, Assignee, Priority and Type, plus any free text you type between them, for example a word that labels the line. They are rendered as one plain line per work item, blocks separated by a single space, and a block with no value simply drops out instead of leaving a gap. A parts list made of free text alone is not accepted: at least one real block has to stay, otherwise every line would read the same.

The default is the summary alone. Add Status if customers should follow progress, add free text to label the line, and leave keys out unless your customers already work with them. Every context of the field has its own answer, so an internal space and a customer-facing service desk can be as different as you need.

The portal reads with the app's permission

Customers are not Jira users of your spaces: they have no permission to browse the work items a request is linked to. Read in their name, the field would simply be empty for them, and the picker on the request form would find nothing. So in the portal, and only there, Linker reads as the app: both the search on the request form and the display on the request itself, whatever the context's Permission model setting says for the internal side.

The JQL filter is your boundary. Because the portal reads with the app's access, the picker there offers every work item the filter allows, and shows the blocks you configured for it. Narrow the field's JQL filter to what customers may see and pick, for example project = CUST AND labels = public, and keep the portal blocks to what is safe to read outside the company. The configuration page repeats this next to the setting.

Nothing else changes: the pick still creates a real Jira link, sync and resync behave as everywhere else, and the person who raised the request is the reporter, not the app. See How linking works.

Without a filter, the field stays empty

The section above explains why the portal reads with the app's access. That has a consequence worth its own heading: the context's JQL filter is not a convenience there, it is the only boundary between your help center and every work item on the site. An empty filter is not a wide boundary, it is no boundary at all. So Linker fails closed rather than open: with no filter set, a Linker field shows nothing in the portal.

That holds on every portal path:

Where	What happens when the filter is empty
The picker on the request form	No suggestions, whatever the customer types. A message under the search box says “This field is not set up for the portal yet. Please contact your service desk team.”, in the customer's own language. It names no internals, because the person reading it is not the person who can fix it.
Pasting a list of keys	Every key comes back as not added.
The values on an existing request	The field renders as None, even when the request really is linked. The customer gets no explanation, on purpose: they are not the person who can fix it.
Creating a work item from the picker	Not available in the portal at all, filter or no filter, see below.

The setup check warns you first. When a service desk space is in the context's scope and the filter is empty, the Check your setup card on the field configuration page says so and names the spaces, so you normally meet this while configuring rather than through a customer. It goes by the spaces in scope, not by request types, so it cannot know whether you actually put the field on a request form: treat it as the reminder it is, and open one real portal request after setting the filter. See Check your setup.

Inside Jira nothing changes. There the picker reads with the searching person's own permissions, Jira's browse permission is the boundary, and an empty filter still means every work item is allowed.

Customers pick, they never create

Inside Jira, an admin can let people create a brand new work item straight from the picker, see Create and link. In the portal that entry is never offered, no matter how the context is configured. Customers are outside your company; they choose from what your filter allows, and they do not open work items in your internal spaces. The one work item a portal form creates is the request itself.

The block is in two places, on purpose: the picker does not show the entry, and the app refuses the request a second time on the server, so the boundary holds even if somebody calls the endpoint directly. There is no setting to switch this off.

What a customer sees when their search finds nothing is therefore a plain “No matches”, with no invitation to create anything. Inside Jira the same empty search would offer the create entry where the context allows it.

The same blocks on both sides of the request. Blocks shown in the customer portal decides what a customer reads on their request and what the suggestion rows show while they pick on the request form, down to the chip for what they have already chosen. So you shape the customer's view once, and keys, statuses and people stay out of the help center unless you put them into these blocks yourself. Your internal Suggestion row setting is untouched and keeps shaping the picker inside Jira.

Before and after

Teams used to bridge this gap with an automation rule that copied the linked work item's name into a customer-visible comment on every change. That still works and stays useful for a notification, but it is a copy: it ages, it repeats itself in the activity feed, and it cannot be corrected. The field shows the current value instead, in the place customers look for it.