Skip to main content
Version: 5.0.0

Fields Required Validator

The Fields Required (Admin Essentials) validator blocks a workflow transition when one or more issue fields are empty at the time of execution. It's useful when a workflow state requires minimum information to move forward (for example, "Resolved" without a root cause, or "In Review" without an assignee).

Unlike marking a field as required globally, this validator lets you define which fields are enforced on each individual transition, without affecting other screens or other workflow states.

When to use this validator?

  • Ensure an issue has a comment before being closed.
  • Require root cause, impact, or action plan to be filled in before moving to "Under Analysis".
  • Enforce that an issue has an estimate or a due date before moving to "In Progress".
  • Force the Assignee field to be set before taking an acceptance transition.
Remember

The validator does not add fields to the transition screen, nor modify the rest of the workflow: it only checks that the fields have values when the transition runs. If you want the user to fill them in during the transition, make sure those fields are included in the corresponding transition screen.

Add the validator to a transition

  1. In Jira, open the workflow you want to edit:

    • For project-scoped workflows: Project settings → Workflows → Edit.
    • For global workflows: Jira settings → Issues → Workflows → Edit.
  2. Select the transition you want to enforce the rule on.

  3. Open the Validators tab.

  4. Click Add validator.

  5. From the available validators list, pick Fields Required (Admin Essentials) and click Add.

    Selecting the Fields Required validator in Jira Cloud's workflow editor

  6. Configure the required fields (next section) and save.

  7. Publish the workflow so the changes take effect.

Configure the required fields

When you add or edit the validator, its configuration panel opens (a Custom UI served by Forge) with three blocks:

1. Dual field list

On the left, Available fields lists every custom and standard Jira field that can be marked as required. On the right, Required fields shows the ones already part of the rule.

  • Click a field on the left and use the button to add it to the required list.
  • Click a field on the right and use the button to remove it.
  • Use the search box at the top to filter by name.

Dual field list in the Fields Required validator configuration

2. Custom error message (optional)

Enter the text shown to the user when the transition is blocked by missing fields. If you leave it blank, the add-on's default message is used; it automatically includes the list of missing fields.

3. Ignore context

The Ignore context checkbox controls how the validator handles custom fields not configured for the current project or issue type:

  • Off (default): fields that don't apply to the issue's context are silently skipped. Useful when the same workflow is shared across projects with different field schemes.
  • On: fields are enforced always, even if they're not configured for the context. Useful for catching misconfigured contexts (the user will see an error on transition).

When you save, the selected fields appear summarized in the transition's validator list. You can edit the validator at any time to add or remove fields.

Behavior at transition time

When a user attempts to run the transition:

  • If all required fields have values, the transition runs normally.
  • If one or more fields are empty, the transition is aborted and Jira shows an error message clearly indicating which fields are missing. The issue stays in the previous state and no change is recorded.

A field is considered "filled" when it has a non-empty value according to Jira's standard rules (non-empty text, a number, a selected date, at least one user in a user picker, etc.).

Error message shown to the user when the transition is blocked due to empty fields

Combine with transition screens

For the best experience, we recommend associating the transition with a screen containing the enforced fields. The user sees the fields to fill in before confirming the transition, instead of discovering the error at the end.

Example: closing an issue with resolution and comment

Consider the "Resolve" transition on a support workflow. The team requires that no issue can be closed without a resolution and a closing comment.

  1. Edit the "Resolve" transition of the workflow.
  2. Add the Fields Required (Admin Essentials) validator.
  3. In the dual list, move to the right:
    • Resolution
    • Comment
  4. (Optional) Enter the custom message: "To close the ticket, you must record a resolution and an explanatory closing comment."
  5. Save and publish the workflow.

From that moment on, any attempt to run "Resolve" without those fields will be blocked with the configured message.

Key differences from the Data Center version

AspectData CenterCloud (Forge)
Config UINative Velocity templateCustom UI served by Forge
Validation runtimeJava plugin on the serverJira expression generated on save
Transition-screen fieldsDirect supportEquivalent support (see technical note)
Global workflowsYesYes
Technical note on Jira-expression generation

On Cloud, the validator does not evaluate fields at transition time by running Java code. Instead, the Custom UI generates a Jira expression when configuration is saved, encoding the rule "every selected field must have a value". Jira runs that expression natively during the transition. This gives the same reliability as Jira's native validation with no performance penalty.