nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

JSM linked form field and request type field displayed without unlink or delete field

Marcel S

Hi everyone, I'm not sure if this was ever a hidden feature or if it was caused by a bug. I have a form attached to my request type, and the description field is linked to it, but at the same time, the description field is also included normally within the request type.

Now, when I create a new request type and try to include both, it either deletes one of them or unlinks the other.

The advantage here was always that if an agent forgot to attach the form because they created the ticket manually, they would at least always see a description and not an empty ticket page with no information.

Is there a workaround for this?

Accepted answers

Gunjan Kumar_xl3r1p

Hi @Marcel S

Yes, this is expected behavior in JSM. If the Description field is linked inside a Form and you also try to add that same Description field directly to the request type, Jira will usually remove one of them or unlink it to avoid showing the same field twice. So unfortunately, this is not a hidden feature you can keep using in Cloud.

The practical workaround is to either use a separate long-text custom field instead of Description, or keep the form as the main intake method and use automation to copy important form answers into the Description after the request is created. That way, agents still see useful information on the ticket even if the form was missed during manual creation.

All comments

Marc -Devoteam-

Hi @Marcel S

If you use the same field in the Request Type and a form containing the same field.

The form is leading.

This has been for quite some time, fields used on the from will remove the field if set in the Request Type as a field.

So when a work item is created via the postal the form field is used, if used internally the work item screen (create) is used.

If later on an internal field the form is added and filed out the original set description will be overwritten

Marcel S

Hi @Marc -Devoteam- ,

"This has been for quite some time, fields used on the from will remove the field if set in the Request Type as a field."

But that’s not the case here. Both fields work. They’re both available. In the customer portal, only the form field is displayed for filling out. Once the issue is created, both the form field and the description field are displayed, which offers the advantages mentioned above.

That’s why the question was whether it was a bug or a hidden feature, since it somehow works without the field being unlinked or deleted

Marcel

Gunjan Kumar_xl3r1p

Hi @Marcel S

Marcel S

Hi @Gunjan Kumar ,

I thought that was normal, but this is the cloud environment, and about 1–2 months ago I somehow managed to add both fields without unlinking one or deleting the other. As you can see in the screenshot, they’re both in the cloud.

In the customer portal, only the form field is displayed for filling out. Once the issue is created, both the form field and the description field are displayed, which offers the advantages mentioned above.

That’s why the question was whether it was a bug or a hidden feature, since it somehow works without the field being unlinked or deleted

Marcel

Arkadiusz Wroblewski

Hello @Marcel S

I would be careful relying on that behavior.

From Atlassian’s side, linked form fields are supposed to handle the Jira field in the background, so normally you should not need to hide that same field again in the request type. Atlassian even says that once a field is linked, it should not appear twice on the portal, and the form value should take precedence.

So if you currently see a setup where both seem to exist in some way, I would not treat that as a clean supported design. It feels more like odd product behavior than something I would build around long term.

If the value should come from the form, let the form own it. If you still need the content elsewhere afterwards, I would rather copy it with automation than depend on this duplicate-looking setup continuing to behave the same way.

Marc -Devoteam-

Hi @Marcel S

These fields are linked.

You're addressing the same field.

So if you create an issue via the create button and fill the description field, the information is shown.

If you later add a form and fill this out, and the description field is linked in the form and the form is submitted, this will overwrite the current description infromation.

Best practice is to let your agents also use the portal to create issues

Gunjan Kumar_xl3r1p

This is probably not a supported feature in JSM Cloud. If both fields showed together in your setup, it was most likely a one-off case or older behavior, not something that Cloud is meant to keep supporting.

So even if it is still working in your current setup, I would not rely on it as standard behavior.

The safer option is to use the form for customer input and then use automation to copy the important answers into the Description field after the issue is created.
Screenshot 2026-03-19 192825.png

Olha Yevdokymova_SaaSJet

Hi @Marcel S
When you link a form field to the Description field, the form essentially becomes the “source of truth” for that field.If you also add Description as a regular request field, Jira tries to avoid duplication/conflicts.As a result, it either:

removes one, or
breaks the linkage

So unfortunately, there isn’t a clean native way to have both a mapped form AND a standalone Description field active at the same time.

Possible native workarounds

A couple of approaches teams usually try:

1. Rely only on the form + make fields required
→ Ensures tickets are never empty, but depends on agents always using the request type.

2. Use automation fallback

Trigger: Issue created
Condition: Description is empty
Action: Add comment or default text

This helps avoid completely blank tickets but doesn’t fully solve visibility during manual creation.

3. Separate “manual intake” issue type

One request type with form
One internal issue type with Description
→ Not ideal, but sometimes used to separate flows

Another approach you might consider

If your goal is exactly what you described —
👉 “even if someone forgets the form, there is still meaningful content in the issue” —
then this is where more flexible form-to-field behavior helps.

With Smart Forms for Jira (developed by our team), you can:

Map form fields not only to one Jira field, but:
- multiple fields or
- aggregate everything into the Description field
Keep Description always visible while still using structured forms
Auto-attach forms based on issue type so agents don’t forget them
Even fill or update Description after submission

For example:

Form responses → mapped to structured fields
At the same time → full summary pushed into Description
→ so even without opening the form, agents see context immediately

This kind of dual-layer setup (structured + readable fallback) is something many teams use to avoid empty tickets while keeping forms.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-service-management-cloud

jira-service-management