Connect more than one Issue Type to the same Request Type

[Abdulaziz Mansour]

I'm trying to add multiple Issue Types as options for the same Request Type, but it seems that the Request Type could only be connected to one Issue Type. Once I choose a different Issue Type for an issue, its original Request Type disappears and I can't choose it back, unless I change the Issue Type back to its original value.

Is there a way to implement that?

[Jack Brickey]

Hi @Abdulaziz Mansour , correct, a request type can only have a single Issue type. I am struggling to understand the use case where you would need two issue types and how that would be presented to the Customer. 

[Abdulaziz Mansour]

Thanks, @Jack Brickey - as far as I know, the issue types are not shown to the customers. What I'm trying to do is to have some sort of categories for the issues (e.g. bug, feature request,...) which would only be filled in by agents. So, a customer could raise an issue, which would have a default issue type initially, but agents could change that issue type later, while retaining the same request type.

[Jack Brickey]

What you are describing, seems to be exactly what the request types and their association with the issue types is designed to achieve. Request types, allow you to present more common language to the customer in an effort to steer them towards the proper input form. Underlying these request types, the issue type allows proper behavioral concepts to be applied such as workflows. As an example, you might have two or three different request types that ultimately would resolve into a single “feature request”. Does this make sense?

please note, that the agent can change the issue type using the move feature if needed. The key to make this successful is to ensure the request type is also changed properly. 

[Abdulaziz Mansour]

Yes, that makes sense, but probably wouldn't help in our use case unless we re-structure everything I guess or think of another way. We have multiple products which we are using as "request types", so the customer can choose the product when they open the request regardless of what the issue type is. Each of these request types (products) could have any of the issue types (FR, bug, etc...), which agents could change.

If I understood you correctly, it wouldn't work that way, would it?

[Jack Brickey]

I do think you need to consider rethinking your approach. I would suggest the using Groups for your products. Here is an example where products are groups and request types are under the groups.

Product A (group 1)

• UI Enhancement (Issue type Feature)
• UI Issue (Issue type Bug)
• Can't log in (Issue type IT Help)

Product B (group 2)

• Suggest Improvement (Issue type Feature)
• Error message (Issue type Bug)
• General Question (Issue type IT Help)

[Abdulaziz Mansour]

Thanks! I will discuss that approach internally with the team.

Appreciate the support.