The Field That Vanished From the Screen
A company-managed project uses a field configuration scheme with three field configurations mapped by issue type: Bug, Story, and Task. A custom field "Root Cause" (single select) was created and added to the Bug screen. Users report that Root Cause does not appear when creating a Bug, but it does appear when editing an existing Bug. The field is required by a validator on a workflow transition. A second custom field, "Customer Impact" (number), was recently made required at the field-configuration level for all issue types. Since then, users cannot create Stories because the create screen does not include Customer Impact. There are 90 open Stories.
1. Explain the difference between the create and edit symptoms for Root Cause, and why the field configuration matters.
Read the worked answer
The create screen and the edit screen are separate screen configurations. A field appears on create only if it is on the screen associated with the Create operation in the screen scheme; it appears on edit only if it is on the screen associated with the Edit operation. Root Cause was added to the Bug screen, but if the create operation uses a different screen (for example, a shared "Default Create Screen"), the field will not show at creation. Editing an existing Bug uses the edit screen, which does include the field, so it appears there.
The field configuration is a separate layer. Field configurations control whether a field is visible, required, or read-only for an issue type, but they do not put a field on a screen. A field must be on the screen and not hidden by the field configuration to be usable. In this case, Root Cause is on the edit screen and presumably visible in the Bug field configuration, so editing works. On create, the screen is the blocker.
The validator on the transition is a third layer: it enforces a value at transition time. If the field is not on the transition screen and has no value, the validator blocks the transition. That is consistent with the report that the field exists on edit but the transition still fails for issues created without it.
2. Diagnose the Story creation failure and describe the fix, including how to avoid breaking the 90 existing Stories.
Read the worked answer
Customer Impact was made required in the field configuration for all issue types, but the create screen for Stories does not include it. Jira enforces required fields at creation; if a required field is not on the create screen, the user cannot supply it, and creation fails. The fix is to reconcile the screen and the field configuration.
Options: (1) Add Customer Impact to the create screen used for Stories so users can supply it. This is the cleanest fix if the field is genuinely required at creation. (2) If the field should only be required later in the lifecycle, remove the required flag from the field configuration and enforce it with a validator on the relevant transition instead. This is often better because it avoids forcing a value before it is known.
For the 90 existing Stories: making a field required in the field configuration does not retroactively populate values, but it can cause edit operations to fail if the field is missing on the edit screen. Verify the edit screen includes Customer Impact, or users will be blocked when editing old Stories. If the field is required and blank on existing issues, consider a bulk edit or automation rule to populate a default, but only if a sensible default exists; do not fabricate data.
Decision guidance: required-at-creation is appropriate for fields known at intake (e.g., summary, reporter). Fields discovered during work (root cause, customer impact) are better enforced by transition validators.
3. A colleague proposes adding every custom field to every screen to prevent this class of problem. Evaluate.
Read the worked answer
It prevents missing-field symptoms but creates worse problems. Screens are the user interface; adding every field to every screen makes forms long, increases the chance of users entering wrong data, and slows issue creation. It also obscures the intended process: if a field is only relevant to Bugs, showing it on Story creation invites misuse.
There are also configuration interactions. A field that is required in a field configuration but irrelevant to an issue type will block creation for that type if it is on the screen and left blank. Adding all fields everywhere multiplies these conflicts. Field-level security and read-only settings become harder to reason about because the same field appears in many contexts.
The better discipline is intentional screen design: define which fields are needed at create, edit, and each transition, and map screens by operation and issue type. Use field configurations to enforce required/optional per issue type, and use validators for transition-time requirements. Document the mapping so future field additions have a clear checklist: create the field, add it to the relevant screens, set field configuration behavior, and test create/edit/transition for each affected issue type. The goal is not to eliminate the possibility of mistakes but to make the configuration legible.