Hi.
We have a Jira project where we need more than 30 request types. We are currently set up as a next-gen project but we are curious if classic projects have access to more request types.
I have seen other tickets where the have been responses telling us to users to use fewer tickets but because we are a next-gen project there are certain limitations (like the inability to transfer tickets between projects) that require us to have a large number of request types in certain projects. Additionally, there is no way to combine our request types without making it too complicated for the end-user because there is no If/Then Functionality in request types. We would like to know if there is a way to get additional request types.
I'm afraid there's no way to increase the limit.
I think you'll need to do some analysis/service design, starting with the question of why you think you need more than 30 types (most of us start to question it at 16+)
I wasn't aware of this limit. I searched the documentation and couldn't find anything. We also have a lot of request types because we want to enforce different input fields for requests. It's not just used for system issues etc.
I don't agree that it's bad design to have lots of request types.
There is no ability to set conditional visibility for fields which would have solved the issue for us, but we are forced to select different request types.
Is there no way to have this limit removed? Is this called out anywhere in the documentation?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
There's no way to increase the limit.
I still think it's a really poor design to have too many request types. Think of it from the point of view of the customer. They're trying to tell you "X is broken" or "I want Y".
Asking them to select from 87 slightly different request types is a non-starter, you've confused, or worse, alienated, them. The work I've done in the past in analysing helpdesk UIs suggests that most humans won't read beyond the 8th request type, they'll give up, select the one (usually from the first 8ish) that sounds the most generic and waste your time and theirs raising the wrong type. Last week, I looked at two Service Desks (one Jira, one not) that have many request types and hundreds of thousands of requests in them. 99% of the requests in both were raised with one of the first five types on the list offered to people.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I totally agree, especially from the customer's point of view.
However, if we had more generic forms, we would then have to follow up with a form with the information that we need to service their request. As we have a global user base if they don't provide these relevant details it can add 24 hours to the resolution times whilst we wait for them to come back online etc. We also then lose the the ability to enforce the entry of this information using mandatory fields, dropdowns etc.
The "wizard" style of conditional logic would help tremendously in simplifying requests. I see that this is on the roadmap with the integration of ProForma request forms. This will help tremendously.
We are trying to balance complexity of having multiple request forms against speed of service. So, whilst I agree with the ideology, I'm finding Jira Service Management restrictive in making this a reality for us at the moment.
The Request Groups have also helped reduce the complexity for the customer.
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.