Comments not updating status in Jira Service Management Cloud
Platform Notice: Cloud - This article applies to Atlassian products on the cloud platform.
要約
On Jira Service Management one of the most common automation rules is the one that transitions tickets between WAITING FOR SUPPORT and WAITING FOR CUSTOMER.
This rule exists both in the Automation (Former Automation for Jira app) and Legacy automation.
Please, expand below to view both rules on their default configuration:
When the Status is not changed automatically on the tickets, it means that one or more conditions were not matched.
How to identify what caused the issue?
Each automation has its Audit log and from there, we can check where and why it failed to be executed.
In this documentation, we will focus on the most common issue when it comes to Automation not changing the status. The main cause is the following:
The assignee or the agent/administrator who added the comment is also 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 it won’t be executed.
This also causes issues with SLA as we can see in the following documentation:
The Audit log
オートメーション：
Go to Project settings > Automation > Click on the desired automation rule > Audit log.
By clicking on Show more under Operations we can see more detailed information about the execution.
Different from the Legacy automation logs, it doesn’t explicitly say the condition that failed, but it will list each condition and say if it passed or not.
In the following example, the ticket was shared with an Organization and the Assignee was a member of the Org as well. As we can see, no actions were performed by the automation since it didn’t match the condition.
As we can see on 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 the WAITING FOR SUPPORT, we can then confirm that what failed was 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.
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.
A successful transition from WAITING FOR CUSTOMER 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.
Legacy automation:
If you don't see Legacy automation in your instance, please refer to the following announcement: Legacy automation is being superseded by Automation in Jira Service Management
Go to Project settings > Automation > Legacy automation and click on View log:
On the logs, it’s possible to see why the rule was not executed by clicking on Show details.
Refer to the below screenshot to view an example of when the automation was not executed due to the Assignee also being a Request participant on the ticket.
As we can see:
A comment was added.
The status was WAITING FOR SUPPORT and Request type was not empty.
The comment was public
User is not a customer
This said, it failed due to the rule considering the person who added the comment as a Customer.
Then, it jumped to Otherwise, if these match..., but the condition was also false.
The same issue will happen if the Assignee is listed on an Organization the ticket was shared with.
Removing the Assignee from the Request participant field, made the rule execute as expected.
How to avoid this issue?
It’s always important to differentiate and add users and customers to their respective roles on a ticket.
The agent who needs to help a customer, in this case, the assignee must be the assignee only, there is no reason for them to be part of an Organization or be added as a Request participant.
As an Assignee, they will have access to the ticket internally and receive notifications.
In case another agent is required to collaborate on a ticket, they can be added as a Watcher so they will receive notifications and this is also true for Administrators if they need to be updated for specific tickets or need to communicate with the Customer.
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).
More details about each type of account on the documentation below: