Auto-Transition Jira Issues When a Comment Contains a Keyword

The problem: comment-driven status changes are manual

When a reviewer writes "approve" in a Jira comment, someone still has to notice it, confirm the intent, and move the issue to the next status. That manual step adds latency and is easy to miss on busy boards. Jira Automation can watch for comment text and transition the issue automatically, removing the human step for predictable keywords.

Useful takeaway

Build a rule with an Issue commented trigger, a condition that checks the comment body for your keyword, and a Transition issue action. Test it in a sandbox project first, because a loose condition can fire on unintended text and consume your automation quota.

Worked example: approve keyword to Approved status

The following rule configuration assumes Jira Cloud with the built-in Automation app. Menu labels vary slightly by edition and version, so treat the names below as the logical components rather than exact screen text.

Trigger: Issue commented

• Fires when any user adds a comment to an issue the rule can see.

Condition: Comment body contains approve

• Restricts the rule to comments that include the literal string approve. In some versions you implement this with an advanced compare condition using the smart value {{comment.body}} and the operator contains. The smart value {{comment.body}} refers to the text of the comment that triggered the rule; misspelling it or using an issue-level smart value such as {{description}} will cause the condition to fail silently.

Action: Transition issue to Approved

• Select the target status from the workflow. The status must exist in the issue's workflow and be reachable from the current status by a valid transition. If the workflow does not allow that transition, the action fails and the audit log records the error.

Save the rule with a descriptive name such as Auto-approve on comment keyword. Do not enable it on production projects until you have run the verification steps below.

How the mechanism fits together

Jira Automation rules are event-driven. The trigger listens for the comment event, the condition acts as a filter, and the action performs the workflow change. Smart values are the placeholders that carry data from the trigger into the condition and action. Because the rule runs as the actor who triggered it—or as a configured rule actor—it needs permission to transition the issue and to read the comment. Users without the Automation for Jira global permission cannot create or administer rules; a rule saved by an unauthorized user may appear in the audit log as failed rather than executing.

Limits to plan around

Automation usage is metered. Plan caps differ: for example, Free plans are typically limited to 1,000 runs per month, while Standard plans commonly allow 1,700 runs per user. Each rule execution must also finish within five minutes; a rule that waits on slow external calls or loops can hit that ceiling and be terminated. When a project exceeds its quota, further executions are throttled or skipped, so a broad comment trigger can burn through the allowance quickly if the condition is too loose.

Common mistakes

• Wrong smart value syntax. Using {{issue.comment.last.body}} when the trigger context expects {{comment.body}}, or omitting the double braces, produces a condition that never matches. Check the execution details in the audit log to see which smart values resolved to empty strings.
• Condition on the wrong field. Placing the keyword check on the issue description or summary instead of the comment body means legitimate comments are ignored. The condition must evaluate the comment text that arrived with the trigger event.
• Circular transitions. If the target status has its own automation that posts a comment containing the same keyword, the new comment re-triggers the rule, creating a loop. Each loop iteration consumes quota and can hit the five-minute execution limit. Guard against this by excluding comments authored by the automation rule actor, or by using a keyword that the downstream automation does not echo.
• Missing workflow transition. The action fails if no valid transition connects the current status to the target status. Verify the workflow in Project settings → Issues → Workflows before enabling the rule.

Verify the result

Create a test issue in a sandbox project and add a comment containing the word approve. Then check the issue history for a transition entry to Approved. Open Automation → Rules → Audit log and confirm a successful execution entry for your rule; the run count should increase by one. If the transition did not occur, inspect the execution details for condition failures, permission errors, or missing workflow transitions. Add a second comment without the keyword and confirm the rule does not fire.

Rollback

Because an enabled rule changes issue state automatically, the rollback is to disable the rule. Open Automation → Rules, locate the rule, and toggle it to disabled. Any issues already transitioned by the rule remain in their new status; revert them manually if needed. Disabling stops future executions but does not refund quota already consumed.