Cost Center: required-ness, option bleed and a duplicate field
You are adding 'Cost Center', a single-select custom field, to a company-managed Jira Cloud site with 60 projects. Requirements: required on create for the 12 FIN projects; optional for OPS; invisible in HR. Monday's test results: (1) FIN users can create issues with no Cost Center; (2) OPS users see FIN-100 and FIN-200 in the dropdown and can select them; (3) HR users still see the field on issues even though the HR field configuration is set to hide it; (4) on FIN issues users set a value on Edit, and when the issue is reopened the value is empty. There is one field configuration scheme in use per project, and the field currently has a single global context containing all three options.
1. Diagnose symptom (1): the field is marked required but FIN users create issues without it.
Read the worked answer
Required is a field-configuration property, but it is only enforced where the field actually appears on the screen the user is completing. Check in this order:
- Is Cost Center on FIN's Create screen? Resolve FIN's screen scheme → the screen used for the Create operation → look for the field. If it is absent, Jira never prompts for it and the required flag is silently ignored. Fix by adding the field to that screen (or routing the Create operation to a screen that has it).
- Is FIN actually associated with the field configuration you edited? Field configurations and field configuration schemes are separate objects; editing a configuration changes nothing until the scheme is associated with the project. Also check per-issue-type mappings inside the scheme - one issue type can be routed to a different configuration where the field is optional.
- Know the loopholes: creates via API or bulk edit can bypass a required field that is missing from the create screen, while a field that is present on a transition screen becomes required at that transition instead. Decide where you actually want the enforcement.
2. Diagnose symptom (2) and specify the fix, including the side effects of changing options.
Read the worked answer
Options are controlled by the field's context, not by field configuration. Right now one global context holds FIN-100, FIN-200 and OPS-300, so every project in the site sees all three.
Fix: split the field into contexts.
- Context A applied to the 12 FIN projects: FIN-100, FIN-200.
- Context B applied to the OPS projects: OPS-300.
- Leave a default context for projects you have not mapped, and check the 'unmapped' warning list before saving.
Side effects to plan for:
- Option lists are not shared between contexts - OPS-300 must be re-created inside context B.
- Contexts match by project and optionally issue type; a project can match only one context per issue type, and overlapping contexts resolve by specificity.
- Changing options never rewrites history. Issues already carrying a deleted option keep the raw stored value; it is shown but can no longer be selected. Report on those issues before you delete an option.
- Do not solve this by creating a second field - that is exactly how symptom (4) happens.
3. Diagnose symptoms (3) and (4), and state the prevention.
Read the worked answer
(3) HR still sees the field because the scheme you edited is not the one HR uses. A field configuration scheme associated with zero projects changes nothing. Open Project settings → Fields for the HR project and read which scheme, which field configuration, and which per-issue-type mappings actually apply. Also confirm the hide was saved on the configuration the project resolves to.
(4) A value that 'reverts to empty' is the signature of duplicate custom fields with the same name. The Edit screen carries field A, the View screen or filter column shows field B. Users save A and read B, so the value looks lost. Audit the custom field list sorted by name for two entries labelled 'Cost Center', check contexts on both, and remember that deleting a custom field destroys its data permanently - consolidating back to one field means migrating values first.
Prevention: record the field ID, context and associated projects in the project's admin notes the day it is created; name-check new fields before creating them; and always test as a real user in each affected project rather than from a site-admin view, which resolves fields differently from what end users see.