How to best utilize "Issue Type"?

[Ken Uehling]

I am currently creating a JIRA Kanban board to handle all incoming refund requests from our customer account managers. There are currently two refund management teams and depending on the nature of the refund (Refund Type #1 / Refund Type #2) one of the corresponding teams will be responsible for it. In the future, those two refund management teams will be combined. But, in the meantime, it would be nice when a customer account manager creates an issue on the board that they have a convenient way to label which refund type to create the ticket for. 

Would utilizing "Issue Type" be the best way to go about this? I currently only have one issue type available to select - "Task". Both refund type's will have the same fields but, as I mentioned before, would like a way for the customer account manager to label their ticket so we know who needs to work on what. 

I created a custom field where the customer account manager can select "Refund Type #1" or "Refund Type #2" but I'm wondering if there is a better way to go about this? Thank you. 

[Joe Pitt]

Your solution would work just fine. If you had two issue types named Refund 1 and Refund 2 it would give easy visual recognition of what type they are.  On the other hand, if you have a select list for 1 or 2 required at creation time if you ever need another type, say 3 you could easily add it to the select list. 

[Marcin Żurawiecki]

Hi Ken,

Let me first ask if I get your desired process right. 

1. A manager creates an issue with the information about the refund type.

2. Someone reviews this issue and based on this information creates another issues for the refund.

3. The refund issue is processed by right refund team.

Considering the above, I would certainly not go with 2 issue types, one for each refund. You just need an issue type Refund and a custom field Type. The name of the field should be universal, because you will be able to easily reuse it in other projects if there is a need in the future. Components are designed to split your whole project into smaller pieces and here we are talking only about refunds. Although if you are not using components now and do not plan to use them as the book says, it's also an option for you.

Generally, good practices state that your Jira configuration should be as universal and small as possible, but also functional! :)

[Ken Uehling]

Hi Marcin, 

Thank you for your response. Here is my desired process:

1) Customer Account Manager creates an issue with the information about the refund type - Refund Type #1 or Refund Type #2 (Currently those two refund types are part of the "Issue Type" so they can be easily viewed on the Kanban board)

2) The refund team will view this issue and complete it. 

That's it!

[Joe Pitt]

The advantage of using components like @Gezim Shehu [Communardo] said is you can automatically assign the issues to a component lead if that would be of value in the approval/review process. 

[Gezim Shehu [Communardo]]

Hi,

Great question. Best practices about abstracting JIRA "parameters/attributes" are always good discussions.

In my opinion, Issue Type should be really used to answer the question "What is it?". In your case a refund.

You have to keep in mind the way the issue type really works, so configuration wise. 1 workflow x 1 issue type, 1 set of field. If these are the same, than I would go for issue type "Refund".

Regarding labeling, depending  on the project, I would suggest either simple "labels" or a custom field to go along.

Although components are an option too. Just usually I've seen them used in different ways, not just to categorize within the same thing.

Best Regards