Required Field Validator vs. Field Configuration: Which One Actually Blocks the Transition
A service management workflow for project ITSM has three transitions: Open → In Progress, In Progress → Resolved, and Resolved → Closed. The Resolution field is on the Resolve screen but not on the Close screen. A required-field validator on the Resolved → Closed transition demands Resolution be non-empty. Field configuration for the issue type marks Resolution as optional; a separate field configuration used by a different issue type marks it required. Users report that closing works for some issues and fails with "Resolution is required" for others, and that after a bulk transition of 200 issues, 37 failed. The bulk operation ran with the default "skip invalid transitions" behavior off.
1. Explain why the validator fires for some issues but not others, and whether the field configuration setting is relevant.
Read the worked answer
Two distinct mechanisms are in play and must not be conflated:
- Field configuration "required" is a screen-time constraint: it makes the field mandatory when a user edits an issue through a screen that contains it. It does not evaluate the stored value on a transition that doesn't render the field.
- A required-field validator on a transition evaluates the stored value at transition time, independent of the screen. If Resolution is empty in the database when Resolved → Closed executes, the validator fails - even though Resolution is not on the Close screen and even though the field configuration says optional.
So the validator, not the field configuration, is what blocks the close. The field configuration is a red herring for this failure mode (it matters only when someone edits via a screen containing Resolution).
Why some issues pass: those issues already have a Resolution value stored (set during an earlier resolve, by a post function, or via import). Issues resolved through a path that never set Resolution - e.g., a different transition, an automation rule that skipped it, or an import that left it null - have an empty value and fail the validator. The 37/200 bulk failures are exactly the subset with null Resolution.
2. The team wants bulk close to succeed without weakening the rule. Propose a fix and explain the ordering constraint.
Read the worked answer
Do not simply delete the validator - the business rule (you cannot close without a resolution) is legitimate. Instead make the workflow guarantee the value exists before the validator runs.
Recommended fix: add a post function on the Resolved → Closed transition that sets Resolution to a default (e.g., "Done") only when it is empty, placed before the validator in the transition's post-function order. Post functions execute top-to-bottom; validators run before post functions, so a set-value post function on the same transition cannot satisfy a validator on that transition. Therefore the correct placement is one of:
- Put the set-Resolution post function on the In Progress → Resolved transition (so Resolution is always populated at resolve time), leaving the Close validator as a safety net. This is the cleanest and fixes the root cause.
- Or run a one-time bulk edit setting Resolution on the 37 null issues, then re-run the bulk transition.
Ordering constraint to state explicitly: validators evaluate before post functions on the same transition, so you cannot "set then validate" within one transition. Backfill must happen on an earlier transition or via bulk edit.
Also note the bulk operation behavior: with "skip invalid transitions" off, the whole batch can abort on the first invalid issue depending on the operation; enabling skip-invalid lets valid issues proceed while you remediate the rest. Verify by re-running on a 5-issue sample first.