I often receive questions from JIRA users arising from a lack of understanding of the underlying system architecture. It is not unusual to desire some functionality and instinctively know there must be a way to do it with the data and the tools available, but not quite grasp the best way to accomplish it. Often users do what they have done with their computers, phones, and tablets: they go to the marketplace. I have found that almost all of the needs of an organization can be met by the core system. This is not to say there is a lack of value in the marketplace add-ons, some can be tremendously helpful, but I find it problematic to rely on an external plugin for critical functionality.
One core JIRA feature that is often under-utilized, and can be an answer to many perceived needs, is Custom Issue Types. Let’s take a look at four scenarios where a user might be tempted to look at add-ons for something JIRA can do with Custom Issue Types.
Need 1: I need a template for recurring and repetitive issues, how do I do that?
I find the strongest solution to be using JIRA’s custom issue types. If for example you have a background check requirement for new hires in your HR workflow, simply create a background check issue type. You can then associate fields, and custom screens with this issue type within your project..
Need 2: I have a particular aspect of our projects that is managed by a central group. How do I aggregate these into a single manageable list?
You can use a custom issue type to accomplish this goal on a per-project basis or across multiple projects. A filter, which can be selectively shared, can be created to display this custom issue type. This filter can then be used to create an agile board or a simple list view that will show issues across all projects that match the search criteria. Continuing with the background check analogy, if there is a central group that manages HR for a number of organizations, the filter can give them visibility to manage the process easily.
Need 3: I need to give an external user access to a part of our projects. How can I do this without that user seeing everything?
Using a security scheme that restricts a user to seeing only certain issue types will achieve this goal. JIRA’s issue security feature is an often overlooked aspect of issue management in JIRA, but one that offers a lot of possibilities. That same HR group likely has no business reading all the details associated with the projects they have to touch. Issue security can restrict their access to only what they need to see–limiting liability. This is a topic I can address in more detail in a separate article. (putting this on my to-do list)
Need 4: I have different types of work in my project. My workflow works for most of my process, but to accommodate everything would require a very complex workflow. How do I accommodate all the types of work within a manageable workflow?
Using custom issue types allows you to select a workflow specifically for each type of issue. This gives you a clean palette to customize how the work occurs, is tracked, etc. Your workflows do not even need to be based on the same principles when split by issue type. I wrote about this in a recent article. You can even send data and triggers to external systems through the transitions of your custom workflow. A background check is an example of a fairly unique process that could easily justify a unique workflow.
Conclusion
All of these needs can be met by utilizing custom issue types. I hope you can see how the combination of all of them makes managing the specific example a breeze. Many of these needs are real and have value across a large number of organizations. Exploring the toolbox in JIRA is important if you want to use the tool effectively. Like anything in life, a deep understanding will almost always yield a better result.
