You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
Next: Root
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
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.
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.