Comments fail to update status in Jira Service Management Cloud

Platform Notice: Cloud Only - This article only applies to Atlassian products on the cloud platform.

Summary

A default automation rule in JSM is the one that transitions tickets: When a comment is added → update the status. This article focuses on the most common causes why the rule may not run as expected.

Solution

The user who added a comment has multiple roles in the request

The most common cause for the rule to fail is when the person (assignee or agent) who added the comment might also be listed as:

  • Reporter.

  • Request participant.

  • Member of an Organization the ticket was shared with.

When an agent (licensed Jira Service Management user) is part of a Customer role, the Automation will fail to check the permission and will not run correctly.

This also causes issues with SLA, as you can see in Time to first response SLA not stopping when an agent adds a comment to the ticket.

Use the automation audit log to track which conditon failed

Using the rule execution Audit log, you can track which of the rule's conditions failed. Below are some examples of the rule's execution.

Example 1

In the following example, the ticket was shared with an Organization, and the Assignee was a member of the Org as well. As you'll see, no actions were performed by the automation since it didn’t match the condition.

Automation rules and audit log side-by-side: arrows showing the connection between the log outcome and the rule

As seen in the screenshot:

✔️ The first condition passed since the comment was not internal.

❌ The second condition didn’t match. When accessing the ticket and confirming that it was on Waiting For Support,but it was failing the part that the Initiator is not a customer.

❌ On the third condition, the first IF passed since the initiator was considered a customer, but it then failed because the status wasn’t Waiting For Customer.

ℹ️ The same issue will happen if the Assignee is also listed as a Request participant on the ticket.

Example 2

audit log showing all successful actions and transition to waiting for customer

A successful transition from Waiting For Support to Waiting For Customer:

✔️Comment is not internal.

✔️ Initiator is a not Customer and the status is Waiting For Support.

✔️ Ticket transitioned to Waiting For Customer.

Example 3

A successful transition from Waiting For Customer to Waiting For Support:

audit log showing all successful actions and transition to waiting for support

✔️Comment is not internal.

❌ Initiator is not a customer and the status is Waiting For Support.

✔️ Initiator is a customer and the status is Waiting For Customer.

✔️ Ticket transitioned to Waiting For Support.

How to avoid this issue?

As a general best practice when using JSM, it’s important to differentiate agents and customers in a request.

An agent working on the request should not be a request participant or part of an organization in the ticket. In case another agent is required to collaborate on a ticket, they can be added as a Watcher.

The Organization and Request participants should only include:

  • Portal-only customers (external unlicensed users).

  • Internal customers (internal users with Atlassian accounts, but with no product access).

  • A licensed user can be added with caution: if they are not an agent of that specific project and have no internal access to the project, they can only access the request via portal.

More details about each type of account on the documentation below:

Updated on June 24, 2025

Still need help?

The Atlassian Community is here for you.