AI Validator
A hard block on the transition, judged by the AI on every attempt, with the refusal message you wrote.
What it does. The user clicks the transition. The app sends the live issue and your rule to the AI, and if the verdict is not allowed the transition is refused and Jira shows the message you wrote.
This one runs the AI inside the user's click
Unlike the AI Condition, the validator generates no expression. There is a model call on every attempt at the transition, by anybody, on any path — a person, Jira Automation, another app, the REST API. That is what buys it judgement a Jira expression cannot express, and it is also what it costs: latency inside the user's click, and a model call each time. Where a rule can be settled by comparing field values, the condition is the cheaper and more predictable answer.
Transition → Validators → AI Validator (Workflow Toolkit) → ConfigureIllustration
AI Validator (Workflow Toolkit)
Describe a validation rule in natural language. On every transition, the AI evaluates the rule against the live issue and allows or blocks it. The configuration is saved when you click “Add” or “Update” in the workflow editor.
Rule Description
Description and components required before review
Context Data
Basic fields (summary, description, status, priority, assignee, reporter) are always included.
Change History — last 50 changelog entries
Attachments — file metadata (name, type, size)
Comments — last 20 comments
Validation Rule (Natural Language)
Block the transition if the description is empty or if no components are selected. Allow if the issue has at least one label.
Describe when the transition should be allowed or blocked. The AI checks this rule against the issue every time the transition runs.
Error message
Add a description explaining how to reproduce this, and pick at least one component, before moving it to review.
This is the exact text the user sees when the transition is blocked, so tell them what to fix. The AI’s specific reason for each block is recorded in the Workflow Toolkit audit log.
Test Rule
OPS-4380
BLOCKED — the transition WOULD be blocked (OPS-4380)
The description field is empty and no components are set, so the rule is not met.
The user would see: “Add a description explaining how to reproduce this, and pick at least one component, before moving it to review.”
The fields, one by one
| Field | What it is for | How to fill it in |
|---|---|---|
| Rule Description | A short label, shown in the workflow editor's validator list. | Write it for the next administrator. “Description and components required before review” beats “AI validator 1”. |
| Context Data | What the AI may read beyond the issue's basic fields: change history, attachment metadata, comments, and named custom fields. | The same four toggles as the post function, and the same advice: add only what the rule needs. The base context that is always sent is listed on the AI Post Function page. |
| Validation Rule (Natural Language) | The rule itself. The AI checks it against the issue every time the transition runs. | Say when the transition should be allowed, or when it should be blocked, or both — this field takes either, unlike the condition, which wants the allowing case. The placeholder shows the mixed form: “Block the transition if the description is empty or if no components are selected. Allow if the issue has at least one label.” |
| Error message | The exact text the user sees when the transition is blocked. | This is the field that makes a validator usable. Tell the person what to fix, not which rule fired. Leave it empty and the app fills in a default that names the module but not the remedy. |
| Test Rule | Runs the rule against a real issue and reports whether the AI would allow or block it, and why. | Always use it, with one issue that should pass and one that should fail. When the verdict is blocked, the result also shows the exact message the user would have seen. |
Jira issue OPS-4380 → Transition “Ready for review”Illustration
Jira could not complete the transition
BlockedAdd a description explaining how to reproduce this, and pick at least one component, before moving it to review.
The text is the validator’s Error message field, verbatim. The AI’s reason for this particular verdict is in the audit log, not here.
CancelEdit issue
The AI's reason is not what the user is shown
The model produces a reason for each verdict, and that reason goes to the audit log — it is the answer to “why was this transition blocked?”. What the user sees is your fixed Error message, the same text every time. The split is deliberate: the reason is AI prose about the issue's contents, and that belongs in an administrator's record rather than in a dialog in front of whoever clicked the button.
Writing a rule the validator applies well
- Name fields the way Jira does. The AI reads the real issue, so it sees real field names; a rule about “the estimate” is a rule about nothing in particular.
- Describe the passing case as well as the blocking one. A rule with only a block clause leaves every other situation to inference.
- One requirement per validator. Two unrelated checks are easier to debug — and easier to explain — as two validators with two error messages.
- Write the error message at the same time as the rule. They are the same thought, and the message is the half the user actually reads.
It fails open, on purpose
Three situations make the validator allow a transition it might otherwise have blocked. All three are deliberate.
- No rule is saved. There is nothing to evaluate, so nothing is refused.
- The AI call failed. A broken model call must not freeze every transition on the workflow. The failure is recorded in the audit log as Validator Failed rather than swallowed.
- There is no active licence. The transition is allowed, no model is called, and the skip is written to the audit log — see What happens without an active licence.
So this is a guardrail, not a guarantee
If the requirement is one you have to be able to prove was enforced on every single issue, a rule that passes when the model is unavailable is not the mechanism to prove it with. Use a required field or a built-in validator for that, and use this one for the judgement a field cannot make.
When a validator is the right choice
- You need the block to be unavoidable. A condition only hides a button. A validator refuses the transition on every path, including Jira Automation, other apps and REST API calls.
- The rule needs reading, not comparing. “The description actually explains how to reproduce it” is a validator. “Story Points is not empty” is a condition.
- You are protecting a status, such as Done or Closed, where a wrong move is expensive to unwind.
Automation is subject to validators too
Anything that transitions the issue goes through the validator: Jira Automation, other Marketplace apps, REST API calls. If an automation rule starts failing after you add a validator, the validator is doing its job on data the automation never had to supply before — and your Error message is the text that surfaces in the automation's error, so write it to be useful there as well. Either make the automation set that data, or restrict the validator to the transitions humans use.
You can use both on one transition
A condition for who may move the issue, a validator for what the issue must contain. They are evaluated independently, and the condition comes first: its expression decides whether the button is drawn at all.