Issue Types, Fields, Screens, and Field Configurations
The configuration chain
This domain is a chain of references that candidates must be able to trace end to end: issue type → field configuration (which fields exist and whether they are required or optional) → field configuration scheme (maps issue types to field configurations) → screen (which fields are visible during create, edit, and view) → screen scheme (maps operations to screens) → issue type screen scheme (maps issue types to screen schemes). A field can be present in the field configuration but absent from the screen, in which case users never see it even though it is "on" the issue type.
Custom fields have a context that determines which projects and issue types they apply to, plus a type (text, select, user picker, etc.). Changing a field's type after data exists is restricted, and questions love to test that limitation. Field configuration controls required/optional and description; screen controls visibility and order.
Traps to watch
- Assuming adding a field to a screen makes it appear; the field configuration scheme must also include it.
- Forgetting that the default field configuration applies to issue types not otherwise mapped.
- Confusing a field's context with its screen placement.
Rule of thumb
When a field "does not show up," debug in this order: is it in the field configuration for that issue type, is it on the screen for that operation, and is the screen scheme correctly associated? Fix the earliest broken link.
Worked example: a required field blocks issue creation on one issue type only. The field is required in that issue type's field configuration, not globally-so adjust that configuration, not the screen.