AI Post Function

Do something after the transition: summarise, comment, update fields, create sub-tasks, notify.

What it does. After the transition succeeds, the app does what your instruction says, using only the tools you allow. It runs as an agent: it can call several tools and repeat them, up to 20 iterations in one run, which is why “create one sub-task per acceptance criterion” works.

Why it is different from Jira Automation. Automation does exactly what you configured, step by step. This handles the cases where the action depends on reading the issue, for example “summarise everything that changed and comment with the summary”.

Transition → Post functions → AI Post Function (Workflow Toolkit) → ConfigureIllustration

AI Post Function (Workflow Toolkit)

Configure AI-powered actions to execute after a transition completes. The configuration is saved when you click “Add” or “Update” in the workflow editor.

Rule Description

Close-out summary and resolution

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

Custom Fields

Root Cause (customfield_10233) ✕Impact (customfield_10234) ✕

Instructions

Summarise everything that changed on this issue and add a comment with the summary. If the issue is moving to Done, also set the resolution field.

Describe what the AI should do after the transition. It will use the enabled tools below.

Enabled Tools

Transition Issue — move the issue to a different status

Add Comment — add a comment to the issue

Edit Issue — modify issue fields (summary, priority, labels, custom fields…)

Create Sub-task — create sub-tasks under the current issue

Search Issues (JQL) — search for issues to gather data or check conditions

Link Issues — create links between issues

Create Issue — create any issue type in any project

Send Notification — email assignee, reporter, watchers or specific users

Log Work — record time spent on the issue

When a Run Fails

A post function can never block a transition, so a failed run always completes the transition. Every failure is recorded in the audit log (Jira Settings → Apps → Workflow Toolkit).

Comment on the issue when a run fails

How it works

It can call multiple tools and repeat actions in a loop (up to 20 iterations), so complex tasks like creating several sub-tasks or updating multiple fields are handled automatically in a single run.

What the AI reads — including what you cannot switch off

A base context is always sent

Before your toggles are considered, every run includes the issue's key, summary, full description text, status, priority, issue type, assignee, reporter, resolution, labels, components, fix versions, time tracking, parent, sprint, the transition being performed, the transitions currently available on the issue, all of its issue links, all of its sub-tasks with summary, status and assignee, and your site's issue link types. For each custom field you select, its list of allowed values is sent too.

The four toggles add to that base. Keep them minimal anyway: less context is faster and more predictable.

Source	What it adds	Note
Change History	The 50 most recent changelog entries: what changed, when and by whom.	Labelled “Last 50 changelog entries” on the screen, which is what the backend takes.
Comments	The 20 most recent comments, newest first.	Labelled “Last 20 comments” on the screen, which is what the backend takes.
Attachments	For each file: name, MIME type, size in KB, who uploaded it and when.	File contents are never read.
Custom Fields	The specific custom fields you select, by ID, plus their allowed values.	The picker offers custom fields only.

Instructions

Describe what should happen. Be explicit about conditions, because the instruction is followed literally: “if the issue is moving to Done, also set the resolution field” works; “handle the resolution appropriately” does not.

Enabled Tools: what the AI may do

Nothing happens that a tool does not permit. If a tool is unchecked, the AI cannot use it even if your instruction asks for it — the call is refused as an unknown tool. Enable only what the instruction needs. The list appears in this order, with Transition Issue first:

Tool	What it can do	Risk
Transition Issue	Move the issue to a different status.	High — see the warning below
Add Comment	Add a comment to the issue.	Low
Edit Issue	Change fields: summary, priority, labels, custom fields.	Medium — it edits real data
Create Sub-task	Create sub-tasks under this issue. Unless the model names a type, it uses the project's first sub-task type.	Low
Search Issues (JQL)	Search issues to gather data before acting. Returns 10 results by default and never more than 50.	Low, read-only
Link Issues	Link issues: blocks, relates to, duplicates.	Low
Create Issue	Create any issue type in any project, optionally linked back to the current one. If the link fails, the creation is still reported as a success.	Medium — it can create work elsewhere
Send Notification	Email the assignee, reporter, watchers or named users.	Medium — people receive mail
Log Work	Add a worklog entry.	Low

Transition Issue can chain

A post function that transitions the issue can trigger the post functions of the next transition. Enable it only when you intend that chain, and never in a way that can transition back to where it came from. That is an infinite loop with your name on it.

When a run fails

A post function can never block a transition, so a failed run still completes the transition. What it does not do any more is fail quietly.

Comment on the issue when a run fails: A toggle in the When a Run Fails section, on by default. It adds an internal comment naming the transition and the error, so the failure is visible on the issue rather than only in the audit log. On a service project the comment is not shared with the customer. Turn it off only if you are watching the audit log instead.
Every failure reaches the audit log: Successful and failed runs alike are recorded at Jira → Apps → Workflow Toolkit, with the transition and the error. See the reference page.

An individual tool failure is still quiet

The two mechanisms above cover a run that throws. A single tool that fails is handled differently: the agent is told the call failed and carries on with the rest of its plan, so the run can finish and be recorded as a success having done only part of what you asked. “Some of it happened” is a real outcome, and the issue itself is where you see it. Test on a scratch project before you rely on it.

Three examples that work

Close-out summary: Context: change history and comments. Instruction: summarise everything that changed and comment with the summary; if the issue is moving to Done, set the resolution. Tools: Add Comment, Edit Issue.
Escalation follow-up: Context: comments and the Impact field. Instruction: when the issue moves to Escalated, create a task in the incident project, link it as relates to, and notify the reporter. Tools: Create Issue, Link Issues, Send Notification.
Refinement breakdown: Context: the description and the Acceptance Criteria field. Instruction: create one sub-task per acceptance criterion. Tools: Create Sub-task.

Test on a scratch project first

Post functions write to Jira, and they fail quietly. Publish the workflow on a test project, transition a couple of issues, read what actually changed on them, and only then use it where it affects real work.