Overview and setup

The three modules, which one to pick, and how to add them to a transition.

What it is. Three items you can add to a workflow transition. All three take a rule written in plain English. What differs is when they run and what they are allowed to do.

If the words transition, condition, validator or post function are new, read Jira words used in these guides first. It takes two minutes and this page will make sense afterwards.

Module	When it runs	What the user sees
AI Condition (Workflow Toolkit)	Before the transition button is drawn	Nothing. The button is simply not there when the rule is not satisfied.
AI Validator (Workflow Toolkit)	When the user clicks the button	The message you wrote. The transition is refused and Jira shows your Error message — see AI Validator.
AI Post Function (Workflow Toolkit)	After the transition succeeds	The result: a comment appears, a field is filled in, a sub-task is created.

Condition or validator? Use this rule of thumb

Prefer the condition when the rule can be settled by looking at field values: it compiles to a Jira expression once, and after that every transition is a deterministic check with no AI call and no latency. Use the validator when the rule needs judgement about what the issue actually says — and when you need a hard block on every path into the transition, including Jira Automation and REST API calls. Both explain themselves to the user; the condition by removing the button, the validator by showing the message you wrote.

What the AI actually does, and when

This matters for trust, for latency and for your bill, so it is worth being precise. The three modules do not work the same way, and the difference is the single most useful thing on this page.

Condition: AI runs once, at setup: You write a sentence, the app turns it into a Jira expression, and the expression is stored in the workflow. Every transition after that is evaluated by Jira itself. No AI call happens when a user opens the issue, so behaviour is deterministic and fast, and you can read — and edit — the exact rule being applied.
Validator: AI runs on every transition: There is no expression. The app sends the live issue and your natural-language rule to the model each time somebody attempts the transition, and blocks it when the verdict is not allowed. That buys judgement an expression cannot express, and it costs a model call inside the user's click.
Post function: AI runs on every transition: The action depends on the issue, so the AI is called when the transition happens. It works as an agent: it can call several tools and repeat them in a loop, up to 20 iterations per run, and it can only use the tools you enable.

```mermaid · flowchartExample

flowchart TD U[User opens the issue] --> C{"AI Condition Jira evaluates the stored expression"} C -->|false| H[Button not drawn] C -->|true| B[User clicks the transition] B --> V{"AI Validator model judges the live issue"} V -->|blocked| M["Your Error message is shown"] V -->|allowed| T[Transition happens] T --> P["AI Post Function agent runs the tools you enabled"] classDef ai fill:#EAE6FF,stroke:#5E4DB2,color:#172B4D classDef stop fill:#FFECEB,stroke:#AE2E24,color:#172B4D classDef go fill:#DFFCF0,stroke:#216E4E,color:#172B4D class V,P ai class H,M stop class T go

Where each module sits in one transition. Only the condition is answered without a model call — the other two run inside the click.

The AI is Atlassian's Forge LLM with Atlassian-hosted Claude models. No API key, no outside provider, nothing used for training. Expression generation uses a larger model than the validator and post function, because generating a rule once deserves more care than running it. See Where your data goes.

What you need first

Jira administrator rights, to edit and publish workflows.
A company-managed project. The three modules declare projectTypes: company-managed in the manifest, so Jira does not offer them in a team-managed project at all. That is a deliberate restriction, not an oversight: team-managed support has not been verified on a real site, and Atlassian's own list of team-managed workflow rules does not mention Marketplace rules.
Nothing else to install — no API key, no third-party account, no other app.

Add a module to a transition

1Install the app.
2Go to Jira → Settings → Issues → Workflows and click Edit on the workflow.
3Select the transition you want to control.
4Choose Conditions, Validators or Post functions, then add the matching (Workflow Toolkit) entry.
5Fill in the configuration, described on the next pages, and click Add.
6Publish the workflow. Nothing takes effect until you do this.

Jira → Settings → Issues → Workflows → Edit → Transition “Start progress”Illustration

Add condition

Conditions restrict who can perform a transition and under which circumstances.

	Condition	Description
	AI Condition (Workflow Toolkit)	Define conditions using natural language. The AI generates a Jira expression that is evaluated on each transition to allow or block it.
	Only Assignee Condition	Only the assignee of the issue can execute this transition.
	Permission Condition	Condition to allow only users with a specific permission.

AddCancel

The configuration panel has no Save button

That is not a bug, and the panel says so itself: your settings are stored when you click Add or Update in the workflow editor, and applied when you publish the workflow. If you close the panel another way, the rule is lost.

An unconfigured module allows everything

Every module fails open. The condition falls back to the literal true when no expression is stored; the validator allows the transition when it finds no rule, and also when the AI call itself fails; the post function simply does nothing. So a module that was added but never configured — or whose configuration failed to save — silently permits every transition. That looks exactly like “the app is not installed”, which is why it is worth opening a saved rule to confirm it is really there.

Configuration is limited to 32 KB

Jira caps what a workflow rule may store at 32 KB, and going over makes the save fail. The panel warns you before you click Add or Update. In practice only a very long instruction plus a long list of custom fields gets near it.

Reading a rule without editing it

When Jira opens a configured module in view mode, the app shows a read-only summary: the module type, the rule description, the generated Jira expression and the AI's explanation of it for a condition, the error message for a validator, the context sources, the custom fields involved, your instruction text and the enabled tools. Use it to audit what a workflow is doing without risking a change.

What happens without an active licence

Licensing is enforced, and for this app the enforcement had to be designed rather than switched on. The three modules run inside a customer's transition, so the usual answer — refuse the work — would have meant refusing somebody's transition. The behaviour differs per module, and an administrator wondering why a rule stopped taking effect should read this table before looking for a broken rule.

Module	Without an active licence	Why
AI Condition	Unaffected. It keeps working.	There is no app code to gate. The generated Jira expression is saved into the workflow and Jira evaluates it itself, exactly like a built-in condition, so nothing of ours runs at transition time.
AI Validator	Allows the transition. It does not block, and no model is called.	A validator that kept blocking after a trial expired would freeze the customer's workflow over a subscription they no longer have — and they could not even transition an issue to sort it out. Losing a guardrail is recoverable; a frozen process on a Monday morning is an incident.
AI Post Function	Does nothing at all. No model call, no comment, no field change, no sub-task.	A post function writes to issues. Continuing to change a customer's data after their licence lapsed is worse than the lost revenue, because nobody can tell what is doing it.

Both skips are written to the audit log, so “why did my rule stop firing?” has an answer on the screen. Everything else stays available: the admin page and its audit log, the CSV export, and opening, reading and editing every saved rule. Nothing is deleted and nothing is locked — restoring the licence restores the behaviour with no reconfiguration.