Issue Types, Fields, Screens, and Field Configurations
The visibility chain
A field reaches a user only when every link holds: it exists and has a context matching the project and issue type; it is on the relevant screen (Create, Edit or View); the field configuration does not mark it hidden or read-only; and, to change it, the user has the relevant project permission. A field missing from a screen cannot be edited even if it is required elsewhere.
Schemes map issue types to behaviour
Custom fields are defined globally, but behaviour is scoped. Contexts decide which projects and issue types see the field and which options apply. A field configuration scheme maps each issue type to a field configuration (required, description, renderer, hidden). An issue type screen scheme maps each issue type to a screen scheme, and the screen scheme maps Create, Edit and View to actual screens. Editing a shared scheme changes every project using it.
Traps
- Deleting a custom field permanently strips its data; hiding it in a field configuration is reversible.
- Removing a field from a screen only stops data entry there; the stored value survives - but users will report the field as "broken".
- Moving an issue type into a project requires the target project's issue type scheme to include it.
- A custom field with no searcher configured cannot be used in JQL and will not behave as expected in filters.
- Options on a select list can differ per context, so the same field shows different choices in different projects.
Rule of thumb: say it out loud - on the screen, out of the hidden list, in the right context, and searchable.