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

Creating Custom Fields Shows Up Context Field for all Request Types

Richard Ing

Hi JIRA Community!

As I've been creating new custom fields for use with Service Desk portal and I've noticed that each new custom field I create will be added automatically to all existing request types agent view.

Specifically it shows up under Context Fields. This results in me having to manually re-hide these new custom fields for every Request Type.

The impact is that the agent view whilst working on tickets is filled with heaps of unrelated fields. Our clients will not see this. Below is a screenshot of what we see.

Is this expected behaviour or is there something I should be doing to ensure that this is more scoped? I have tried to only assign it to certain screens but I can't avoid it as I need to assign them to the request type (service request, or incident) in order for this field to be used at all.

Custom Fields.png

Accepted answers

Callum Carlile _Automation Consultants_

Hi @Richard Ing

The new custom fields will only be added as a context field if the field is on the view screen used by the issue type your request is mapped to.

So if you are only wanting to add the new fields to a particular request (without having to manually hide these from the other requests each time) then the request will need to be mapped to a different issue type which uses different screens and screen schemes.

Either that, or you can still use the same screens on the separate issue types, but you will need to create a field context for the new fields which only display the field on that particular issue type which your request is mapped to

All comments

Callum Carlile _Automation Consultants_

Hi @Richard Ing

The new custom fields will only be added as a context field if the field is on the view screen used by the issue type your request is mapped to.

Richard Ing

Hey Callum,

Thanks for your response! I have figured that out after some testing although naturally as a service desk portal, we've configured dozens of different request types which map back to an issue type (eg. request, incident, request with approvals)

For example

Email related requests, we'll have 4-6 different request types associated to the issue type "Service Request". Whenever we add a new custom field, it adds it to every other request type which is a Service Request.

In this case I'm not sure would having different field contexts would help? or At least it seems like alot of overhead of introducing a single extra field that is related to a request type.

Cheers!

Richard

Callum Carlile _Automation Consultants_

@Richard Ing Yeah you're right - a field context can be set for a project or issue type, but as you are using the same issue type for many requests within the same project, the field context would not work as desired.

I think that unless you split out your requests to map to different issue types, the least amount of work would just be to continue as you are and hiding the fields from the relevant requests as they are created. You would hope at some point that this stabilises when you have all of the fields that you require, as like you say, it's a bit of an overhead

Richard Ing

Thank you for helping me confirm my understanding of it. You are right, over time it does stabilize although we regularly add new request types based on customer feedback and we don't want to keep introducing:

- A new custom field

- A new issue type

- A new custom context to then bring it altogether

Dena Campasano

This is incredibly frustrating. This update was introduced after we already set up several Service Desks that share screens and workflows.
I spend hours every month going into every Service Desk and hiding the fields from every form in every Service Desk when a custom field is created.

In addition, when you create a new form, all the custom fields show up and it takes time to hide everything before you even begin customizing your form.

Multi select to drag to Hidden would help, or a template when creating new forms.

Derek F_

We have over 100 request types. Most of them use the same screen. I can't imagine anyone that would want to have a new custom field added to every request type. I do wish this was reversed so users who did want to add a new custom field would have to open all request types and manually add it.

My feature request would be to use a "template" or "field grouping" like (New Hire Name, New Hire Email) and you wanted to add a email field everywhere these fields go, you just add it to the group (New Hire Name, New Hire Email, New Hire Phone).

Side note: I keep a list of the URLs of our request types and load them in a Chrome extension called "Open Multiple URLs" and tab through, removing the 5 fields I added to just one of the request types.

Screen Shot 2023-05-20 at 9.33.28 AM.png

Jeremy Wood_unqaho

@Derek F_ - I'm curious. Did you ever find a better way of doing this?

I'm a new Atlassian admin and have quickly ran into this issue in our environment. Would love to find a better solution then edit every single request type or create 100 different issue types.

Welcome!

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

Quick Links

Find more posts tagged with

custom-field

cloud

jira-service-management-cloud

jira-service-management