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; } } }

Custom fields editable on Request form view AND Work Item view

Myles Boyd

Every time I add a custom field that is on the Request form tab of a request type, to the Work item view tab, it removes it from the Request form.

How do I add custom fields to both the Request item view and the Work item view? I need both the customer to set on logging and the agent to be able to change

Thanks

Myles

Accepted answers

Marc -Devoteam-

Hi @Myles Boyd

You can't.

You can use a field only on a request form or a work item view.

If you use the field on the request tab, make sure the field is on the screen used by the work type.

If this field is filled out in the request type, the field with the value is shown on the work item.

All comments

Marc -Devoteam-

Hi @Myles Boyd

You can't.

You can use a field only on a request form or a work item view.

If you use the field on the request tab, make sure the field is on the screen used by the work type.

If this field is filled out in the request type, the field with the value is shown on the work item.

Myles Boyd

That's a shame;

There are times when a ticket is wrongly raised, and I wanted agents be able to amend the Request Type and populate the required fields on an existing issue. As such, I needed to have the fields on the Request view for customers to complete, and the issue view for agents.

Looks like I will have to duplicate all my RTs !!!

Marc -Devoteam-

Hi @Myles Boyd

If the field is on the request type. and the field is used on creation via the portal, on the work type this field is also visible.

So on the work item you can edit this field and change its value.

Myles Boyd

Thanks Marc, should have tested - was so focused on adding

Olha Yevdokymova_SaaSJet

Just to add one more angle here, since the pain point seems to be fixing or reworking requests after they’re created.

You’re right that natively:

A field used on the request form is visible and editable on the work item
But changing the request type itself (and re-collecting the right info) is where things get messy
Duplicating request types is often the only clean native option, which doesn’t scale well

Some teams handle this by moving the customer input into a form layer instead of relying entirely on request-type fields.

With Smart Forms for Jira (developed by my team), a common pattern is:

Customers submit a form to create the work item
Form fields not always needed to be tied to work item field if not needed for mapping, but if needed you can map any form field to any jira field of that type
Agents can later open the same form or another ( follow-up form) on the work item and this form may update the same work item fields as preuvious
Agents can correct or update details
You only map the fields that Jira actually needs (like Request Type, Category, Priority), instead of duplicating request types just to re-enter data

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