Documentation for JIRA 6.4 (This documentation includes the project navigation sidebar). Not using this? See below:
(JIRA 6.4 without sidebar documentation | JIRA 6.3.x documentation | JIRA Cloud documentation | earlier versions of JIRA)

Skip to end of metadata
Go to start of metadata


To help you tailor JIRA to your organization's needs, JIRA enables you to manipulate the display and behavior of issue fields ('Summary', 'Description', 'Issue Type', etc). You can:


Some key JIRA concepts include:

  • Field Configuration — a set of definitions for all fields, comprising: each field's description; whether each field is hidden or visible; whether each field is required or optional; and what type of renderer to use for each text field.
  • Screen — defines which fields are present on a screen, and their order. (Note that a hidden field can be present on a screen, but will still be invisible.)
  • Screen Scheme — associates different screens with different issue operations (e.g. 'Create Issue', 'Edit Issue', 'View Issue').
  • Workflow — defines the steps (i.e. statuses) and transitions to other steps that an issue moves through during its lifecycle. Screens can also be mapped to different transitions of a workflow.
  • Field Configuration Scheme — associates Field Configurations with issue types, which in turn is applied to projects. This allows you to specify different behaviors for a field, for each type of issue in a given project.
  • Issue Type Screen Scheme — associates Screen Schemes with issue types, which in turn is applied to projects. This allows you to specify different screens for a particular operation (e.g. 'Create Issue'), for each type of issue in a given project. For example, you could use one screen when creating an issue of type 'Bug', and a different screen when creating an issue of type 'Task'.
  • Workflow Scheme — associates Workflows with issue types, which in turn is applied to projects. This allows you to specify different workflows for each type of issue in a given project.
  • Issue Type Scheme — is applied to projects and defines (or restricts) which issue types are available to those projects.
    (info) If the Field Configuration Scheme, Issue Type Screen Scheme and Workflow Scheme associated with a given project contain associations with other issue types that are not specified in the project's Issue Type Scheme, then those other issue types will be ignored by the project since the project's Issue Type Scheme restricts what issue types the project can use.

Related topics



  • No labels


  1. Hi,

    I  personally think this diagram make my it easier to understand JIRA. It just make JIRA concept easy to digest for beginner.

    1. With the diagram, It is very clear for me to understand these concepts.

  2. Anonymous


    when i defined different screens for project conf (issue type screen scheme) and project's workflow transition; which one has priority; Is it possible to define a screen just for a transition other than project's issue type screen scheme. When i tried eg. when i create an issue, actual screen seems as issue type screen scheme not as transition screen

    1. Hi there,

      'Screens' associated with 'screen schemes' (which in turn are associated with 'issue type screen schemes') determine the fields seen whenever you perform an 'issue operation', which includes 'creating', 'editing' or 'viewing' an issue.

      On the other hand, 'screens' associated with 'workflows' (which in turn are associated with 'workflow schemes') determine the fields seen (in a dialog box) whenever you 'transition' an issue to a new status in the issue's workflow.

      Hence, neither of these different 'screen' associations take priority because they appear under different circumstances - one when you create/edit/view an issue and the other when you 'transition' an issue through its workflow.

      To define a screen for just a transition, first define a screen and apply it to the relevant transition. See the Working with Transitions section of the Configuring Workflow page for details on applying predefined screens to transitions.

      Hope this helps!



      1. This is the best thing I've ever read! Thank you!

  3. Anonymous


    I am interested in finding out if fields can be hidden or displayed based on logic.

    For example, when i move a logged issue to "Resolved" status, if i indicate that it was resolved with code change, then the fields like "Check in Label", "Release ID", "component",  etc should be mandatory fields to fill out

    If i indicate it was resolved with a document change, then only "Name of updated document" field should be mandated and other fields should not appear at all.




  4. Anonymous



    I created a project that had 2 custom fields and description.  When i ordered the screen it leaves the description at the bottom.  However the order is meant to be



    Custom 1

    Custom 2

  5. Anonymous

    I did quite a search and cannot find the solution for configuring the same field on different screen as mandatory or not. For example, I have a field "Fixed Version", when I log an issue, I do not need this field as mandatory field, but when I resolve this issue, I need it to be mandatory. How can I achieve this? I use different screens for creating issue and resolve issue.

    Any help is appreciated!

    1. Hi there,

      There are two ways in which you could achieve this:

      1. Using the JIRA Suite Utilities plugin:
        1. Install the JIRA Suite Utilities plugin in your JIRA installation.
        2. Make the 'Fix Version' field optional in your project's field configuration(s).
        3. In your project's workflow(s), apply a 'Fields Required Validator' to your resolve transition.
          (info) See JIRA Suite Utilities Workflow Validators for details.
      2. Making the 'Fix Version' field mandatory in your project's field configuration(s).
        • Omit the 'Fix Version' field from your project's create issue screen(s).

      The first approach provides greater flexibility.

      The second approach doesn't require the JIRA Suite Utilities plugin to be installed. However, you aren't provided with an option to specify a fix version when an issue is created.

      Hope this information helps.



      1. Anonymous

        That's so helpful. Thank you so much for your quick response, Giles.

  6. Anonymous


    I'm looking for a way to have people working on my projects (each representing various teams: TW, WD, ID, AE, AP, etc.) be seen on each issue screen for the project. Now it appears that I can define the "people" at the project level, but then this info is not displayed automatically anywhere else. Is there a way to have those fields populate onto the issue pages for a project?

    Otherwise, I've seemingly accomplished this via custom fields on the issue screens - where I enter the team members. But could these custom fields inherit, populate, and/or sync to the project defined roles? OR to those fileds on other issue screens within a project? So for example, Project X has 2 issue types:

    On issue type 1 screen, I would enter fields for various people/groups/roles on the project.

    On the issue 2 screen,  I want those people/roles to be seen, but rather than enter each of them again, the fields would be inherited/populated and sync'ed to issue 1?

    Is this possible?




  7. Hello

    It seems that the link for 'custom' fields in the Overview section is pointing to the wrong place.

  8. Anonymous


    I'm a little confused re context and screens... what's the easiest way to accomplish this:

    -Add a new text field called RID to only one project (key PRJ) and have it appear on the issue create and edit screens for that project just below the issue summary.

    This should not affect any other project.


    1. During the creation of the custom field you can restrict its usage both to an issue type and a specific project; with that you are at least ensuring that the field won't appear in other projects.

      Now you will want to make sure that it appears in the correct screens and order in your project. For this you'll have to make sure about two things:

      1. That the field is "shown" in your field configuration (a project has only one Field Configuration Scheme, and a Field Configuration Scheme has at least one Field Configuration).
      2. That the field is visible in the screens where you want it to be (a project has only one Issue Type Screen Scheme, and an Issue Type Screen Scheme has at least one Screen Scheme, and a Screen Scheme relates a screen with one of this actions: create issue, edit issue or view issue).

      After checking that you can go to your screen and just change the position of the field.

      I hope that helps you.

  9. Anonymous


    Help me to add a new field which show a message above when an issue created.

    When i create an issue it show more fields required. When above all show this like"This for wiki project". How can do that??



    1. Hello Raj

      I don't think I'm getting your idea... but let me try to explain a little about the required fields.

      You have two options make a field as required:

      1. In your Field Configuration just mark it as Required. This will ensure that your field is always required in any screen, even from the creation. This way you cannot define the message; JIRA predefined message will appear.
      2. Make the field as optional in the Field Configuration but handle it with a workflow condition so that only in certain transition it is required. This way you can define the message to show when the user doesn't fill the field.

      I hope this helps.

  10. Hi, I'd like to configure the Build&Release screen so that I can choose parameters passed to BAmboo from a drop down list. Is that possible?

  11. Hi There, 

    I've got a problem as I've lost my "Fix Version/s" field option in my projects.

    It's in the system configuration and should be showing on all screens but it is missing when I actually try and get it on the project.  

    It's a build in field but I used the "Advanced" section of the Fields Config (in Custom Fields) to make another field that carried out the same function (Version Picker (multiple versions)).


    Can you help?!  I would just stick with this custom value but JIRA Agile puts "Fix Version/s" as default on the Agile config & I don't want to have to change for all projects.



    1. Hi Accounts Accounts,

      I'm not sure what could be causing the field to not show. There's a few things you could check, as an Admin you should be able to see an Admin button when you're viewing an issue. Clicking that will give you options to add the field, or see if it's available. If that still doesn't work for you, I'd suggest contacting our Support team and they can assist you further.



  12. Hi guys 

    Is there a way I can use in the same project different field configurations ?

    I have a field which is optional in default field configuration. However in the workflow, for the transition from "open" to "in progress" i need to use a customized field configuration where I set that field to required. 



  13. This whole scheme thing seems prohibitively complex, especially since there's no documentation that says "to create a new thing here are all the steps across all this silliness from start to finish". Is there a reason why this is process is so convoluted and unwieldy?

    1. Once you understand it you will really appreciate it.

      1. so ... kinda like being a brain surgeon? (wink)

        Yes, I get that it's very powerful and all that, but it just seems that it's a lot harder than it needs be. I've worked with a lot of databases and platforms, and all these schemes, associations, and such are a maze, at best. Even if it is something one appreciates once it's understood, it would be wonderful if someone who understood it would actually write out something like, "if you're creating a new screen for your project, follow these steps".

        1. You could probably create a support ticket with Atlassian Support with your question and they might even surprise you with a link with just the information you need.

          1. LOL! Yep, they sent me to this exact article (wink)

            1. No way!... ok... My approach, in terms of the diagram in this page, is to go from bottom to top. That has worked well for me.