Issue Types, Fields, Screens, and Schemes
What to know
Fields have a type (text, select, user picker, date) and a context that determines which projects and issue types see them and what options apply. A field configuration controls whether a field is required, optional, or hidden, and its description. A field configuration scheme maps issue types to field configurations. A screen is a set of fields shown for an operation; a screen scheme maps operations to screens; an issue type screen scheme maps issue types to screen schemes. Custom field contexts let one field behave differently per project.
Traps
Common confusions: hiding a field on a screen does not make it required or optional; required is set in the field configuration. A field can appear on a screen but be hidden by its field configuration. Custom field context changes affect only the projects in that context. Deleting an issue type can orphan issues unless a migration target is chosen. Also, a field must be added to the screen to be visible even if it is required.
Rule of thumb
Trace visibility in this order: field context, field configuration (required/hidden), screen (present), screen scheme (which operation), issue type screen scheme (which issue type). If any link is missing, the field will not behave as expected.
Worked example
A team wants a "Customer" field required only for the Bug issue type in project ALPHA. Create the custom field with a context limited to ALPHA/Bug, add it to the create and edit screens, then set it required in the field configuration mapped to Bug via the field configuration scheme.