We have setup ten different Request Types in Jira Service Desk. Each of our requests shares the same Issue Type (Service Request) and the same workflow. They also share the same field sets. We just hide the fields we don't need per request type.
However, when I Create an issue I still see all hidden fields on that create screen. Also Jira Mobile displays all hidden fields for all request types instead of respecting the fields I've hidden in the Request Type editor.
Is there any way to resolve this? It's frustrating because we work hard for a clean environment and it's confusing users who are filling out fields that don't go with that specific request type.
NOTE: on my Software & Business Apps Request Type I have hidden Accounts & Passwords Category field.
NOTE: the Accounts & Passwords Category field is present still on the create screen. I cannot remove it from the create screen because then it would remove it for all Service Requests including the actual Service Request where I need that field to be present.
The Create screen is per Issuetype so given you have a single issuetype then if you Create an issue within the application then the fields will be displayed as defined by the Create screen. Now, given that you have multiple Request Types associated with this Issuetype you can display different fields per RT. So creating issues from the portal or if an agent uses the “raise a request” link in the sidebar then they will see only the fields that have been added to the create form.
Regarding mobile, I don’t have an answer for you as I rarely use mobile and when I do I simply accept it for what it is.
Hi Jack,
Thanks for the info. It's a little disappointing that our Service Desk agents would need to go outside of JSD to submit a proper request. Especially when Atlassian slaps a giant Create button prominently our face right inside the tool.
I can understand the limitations on mobile being acceptable for now, especially as the app continue to mature. JSD doesn't seem to be a core focus of the apps feature releases.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
In my experience and opinion, agents should use the “raise a request” most if not all the time. The reason for this is to ensure that the proper data gets filled in: customer/reporter, request type, required fields for the given RT, etc. creating using the Create button yields a different result than what the customer experiences. The Create button is part of Core and certainly serves as the primary method for creating core/SW issues.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Fair enough, I'll definitely take that into consideration. I would argue that my dream/goal of having the Create button match the same fields/experience as the end-user portal would lead to the same results, which is ticket consistency and identical fields between the portal and the create issue screen. But if that's not in the cards then you're right, having them submit issues via the portal isn't a terrible option.
Thanks for the input!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.