How to use field configs correctly/how to have unique issue types in different projects?

[Regan Huisman]

Apologies if this has been asked before, but I am getting really lost in all of the different ways this has been asked/answered in the past, so hoping to gain some clarity by stating my exact use case. My general confusion is around whether or not to utilize a scheme, screen, or field config to achieve my results. Hopefully someone here can help me figure it out! 

We are a small company and just have 2 projects right now.

1. PRODENG (typical roadmap stuff).This project contains all of the classic issue types (Story, Epic, Task, Subtask, Bug). Right now I haven't made any changes to the typical structure of these issue types. 
2. INIT (Technical Initiatives: ops requests, on call chores, tech debt, other extraneous things). And this is where things get confusing. 

In the Tech Initiatives Project, we are using the Nextup slack integration to have our non-jira ops users submit requests of various types as tickets in our On-Call board in this project. We are wanting to create a different issue type with specific custom fields for each "request type" we have available for our ops users. These issue types all need their own custom fields. 

For example, one Issue type we have is called "Pre-Record Request" which needs the following custom fields: Show name, Show Date, Show Admin Link, Download URL, Other Details. I've already created each of these custom fields (all text-multi-line). But am not sure where the association point is for issue type. 

Another example is for bug-submissions. We want a few extra fields to ask questions to the submitter in the issue type "Product Bug" such as: Device and browser, cadence, etc. 

What is the best way to go about setting up a different field arrangement per issue type? Is this creating a new field-config per each issue type? Or is there some way to do this better by utilizing schemes or screens? 

Let me know if I can clarify this in any way or give more specific examples. My ultimate goal is to utilize jira best practice while also fitting it into our unique (or not so unique?) use case!

-- Edit as I'm trying to figure this out myself.. 

I created a Field Config called "Product Bug Field Config" and associated that to the "Product Bug" issue type by using the "Product Bug Field Config Scheme" but it was sadly not reflected in the creation of a new product bug. I'm wondering if it is truly somewhere in the Screens/Screen schemes where I make this type of detailed manipulation per issue type? 

[Kit Friend · Accepted solution]

It's confusing isn't it :) Things have been made a little simpler in Jira Cloud through the new Jira issue view but it's still not very intuitive. In most of the above focussing on the "Screen" element (i.e. what users can/can't see) is probably more important than the "Field" (how the fields behave), but there's a blend of both for some elements. There's a good article worth reviewing at https://www.tempo.io/blog/2015/jira-best-practices-screens-and-screen-schemes 

Best practice wise, I always find it worth focussing on keeping things as simple as possible, especially whilst people learn. There's a tendency to use Jira's ability to have lots of fields to mean people create lots of fields, and tickets become like SharePoint forms where people skip things the whole time. Put in the minimum you need to get some feedback from users, then introduce more complexity if/where you've got evidence it might improve things (i.e. to start with, people should stick almost everything in the Description field)

In all cases, I find it simplest to go via the Project settings. Let's look at where you get to from there:

If you're using Next Gen (DEMO in my screenshot), you're looking for the Issue type area - this lets you manage not only what issue types are available but also what fields are displayed for them:

If you're in a classic project (RANK in my screenshot demo) it's a bit more complex, but you can still find your way via project settings. Start under "Issue Layout" and you'll see which screens are used for which issue types - by default you end up with Bugs separate mostly (there's probably an option I've forgotten which dictates this... not important for this query though). By clicking on the links like "show the fields defined in RANK: Kanban Default Issue screen" you get to the relevant configuration for those issue types:

Here's the aforementioned configuration once you click through where you can show/hide fields:

To create a new separate screen which applies to only your new/seperate ticket types (let's use "ops requests" as an example), you need to create a shiny new "Screen" to associate with those issue types. It's easiest to do this via the Admin cog > Issues > Screens (https://<YOUR JIRA INSTANCE URL>/secure/admin/ViewFieldScreens.jspa ):

Make your new "ops request" (or other) special screen by clicking the "Add screen" button. You'll then need create a Screen Scheme which gives the screen a home to live in. This is less obviously relevant if you've only got one type of screen to use throughout the lifecycle of an issue - it's really designed to cater for people wanting different things to show when doing different actions. This is less relevant these days, hence why it's not needed for the Next Gen answer above. Create a new Screen Scheme in the "Screen Schemes" area under the Admin Cog > Issues (below where you just were to make your new screen). 


Once you've got those both ready, go back to your project settings "Screens" area, and click on "Edit Screens":

...then click on  Associate an issue type with a screen scheme and select the new scheme you made for "Ops request" (or whatever you made). 

Field configuration can mainly be ignored unless you need to control how the fields behave (are they mandatory, what renderer do they use etc). I'd try and get the above working first given that your instance is quite simple. If you want to explore field config, start with: https://support.atlassian.com/jira-cloud-administration/docs/add-edit-and-delete-a-field-configuration/ 

All being well, that's you now sorted. The above assumes you're focussing on screens and fields being configured for one project at a time. If you end up wanting to share some config across multiple projects (e.g. everyone's Ops Request tickets across an organisation have the same fields etc) then you can share the schemes you've made across multiple projects and create some consistency. 

[Regan Huisman]

Kit, thank you so much for your thorough answer. This answered my question perfectly, and also helped me further understand how it all works. My instance is now spun up correctly and working great! Customized Screens per Issue Type worked perfectly. I included a screen scheme per new screen, and I'm pretty sure that's correct too, but let me know your thoughts. Thanks again for the help and time. 

[Kit Friend]

Excellent Regan - glad it worked for you. 

The number of screens per screen scheme is really up to you (I mostly try and keep things simple and use the same one for view/edit/everything) but if it's all looking as you want, that sounds good to me :) 

Happy ticketing!