Summary

This KB article is meant to provide some tips on how to troubleshoot issues where a customer did not receive a notification from a Jira Service Management (JSM) request (while this user expected to receive one). It also lists the most common root causes that have been discovered so far.

This KB article is about JSM Customer Notifications (configured in JSM projects in Project Settings > Customer Notifications), which is a different type of notification than the Jira Notifications configured in Project Notification schemes. To troubleshoot why a user did not receive a Jira Notification, please refer to the other KB article Troubleshooting why a Jira user did not receive a notification from a ticket while this user was expecting to receive it

This KB article only helps troubleshoot why customer notifications were not sent from a specific JSM project/request, for specific actions, or for specific users. If the Customer Notifications are not sent at all from any JSM project and for any user, or are particularly slow, then please refer to the other KB article Troubleshooting slow/stuck notification issues in Jira/Service Management Server/Data Center

Environment

Jira Service Management Server / Data Center. Any version from 4.0.0.

Troubleshooting tips

Understanding the different types of notifications involved in JSM Projects

It is important to note that, in JSM projects, there are 2 main types of notifications that come into play:

• The Jira notifications:
  
  • they are sent to users acting as agents in JSM tickets
  • they are configured through the Notification Schemes, via the page Project Settings > Notifications
• The JSM customer notifications:
  • they are sent to users acting as customers in JSM tickets
  • they are configured through the Customer Notification configuration, via the page Project Settings > Customer Notifications

Depending on the type of notification that was not sent, a different troubleshooting approach will need to be followed. This KB article only helps troubleshoot Customer Notifications. If the issue is about the agent notification (=Jira Notifications), you will need to refer to the other KB article Troubleshooting why a Jira user did not receive a notification from a ticket while this user was expecting to receive it

Understanding the difference between the customer and agent role in a JSM ticket

When a user reports that they did not receive a notification from a specific request, it is important to understand if this user was treated as an agent or as a customer, within the scope of the JSM ticket. A user will be treated as a customer within the ticket if the user verifies any of the conditions listed below:

• the user is the Reporter of the ticket

• the user was added to the Request Participants field

• the user is part of any organization the request is shared with via the Organizations field

• in case the ticket is using an approval workflow, the user is part of the Approvers of the ticket

If the user is treated as a customer, this user should receive customer notifications. If this user did not receive the expected customer notification, then this KB article is relevant.

If the user is not treated as a customer, then this user will instead be treated as an agent and should receive Jira Notifications. In such case, please refer to the other KB article Troubleshooting why a Jira user did not receive a notification from a ticket while this user was expecting to receive it instead.

Conditions required for a user to receive a customer notification from a JSM ticket

For a user to receive a customer notification from a request, there are a few requirements. If any of the requirements listed below are not met, then this user won't receive the customer notification:

• the Request Type field needs to be set to a value in the JSM ticket
• the Customer Notification needs to be enabled in Project Settings > Customer Notifications for the event that should have triggered the notifications
• the user needs to be able to view the JSM ticket from the customer portal view (by being either a reporter, a request participant, an approver, or part of the organization the ticket is shared with)
• the user should not have opted out from receiving customer notifications from that specific JSM ticket

Useful SQL queries for troubleshooting

There are a few SQL queries that can be executed to understand better why a Customer Notification was not sent from a specific JSM ticket, or to a specific user.

SQL Query 1

The AO_4E8AE6_NOTIF_BATCH_QUEUE table in the Jira DB contains data that will be used to generate Customer Notifications from specific JSM tickets and to specific Jira users. Whenever a new event happens in a JSM ticket which should trigger an update to be sent to a customer, a new row is added to this table.

Running the following query will show you all the events that have been triggered for a specific JSM ticket, and whether a Customer Notification has been generated for that particular event.
You will need to replace ABC and 123 with the issue key of the JSM ticket. The query below will work if the key of the JSM ticket is ABC-123
This SQL query was written and tested on a PostgreSQL Database. The syntax will be slightly different on other types of Database

SELECT * FROM "AO_4E8AE6_NOTIF_BATCH_QUEUE" sd
join jiraissue ji on ji.id=sd."ISSUE_ID"
join project pr on ji.project=pr.id
join app_user app on app.id=sd."RECIPIENT_ID"
where pr.pkey = 'ABC' and ji.issuenum = 123;

A few notes about the results of this query:

• If the SQL query did not return any row corresponding to the impacted user, then it could mean that this user was not eligible to receive a customer notification, or that this user opted out from receiving notifications from that JSM ticket.
• The SENT_TIME column shows the time when the customer notification email was constructed and added to the Jira Mail Queue. If this column is empty, then it means that even though an event was triggered, the notification email was not generated yet. 

SQL Query 2

The AO_54307E_SUBSCRIPTION table in the Jira DB will show whether a user has opted out from receiving customer notifications from a specific JSM ticket. If you see a row in that table corresponding to a specific JSM ticket, then it is likely that a user has opted out from being updated from that ticket.

Running the following query will show you the list of users who opted out from receiving Customer Notifications from a specific JSM ticket.
You will need to replace ABC and 123 with the issue key of the JSM ticket. The query below will work if the key of the JSM ticket is ABC-123
This SQL query was written and tested on a PostgreSQL Database. The syntax will be slightly different on other types of Database

SELECT subs."ID", subs."ISSUE_ID", subs."SUBSCRIBED", app.lower_user_name
FROM "AO_54307E_SUBSCRIPTION" subs
join jiraissue ji on ji.id=subs."ISSUE_ID"
join project pr on ji.project=pr.id
join app_user app on app.user_key=subs."USER_KEY"
where pr.pkey = 'ABC' and ji.issuenum = 123;

Common Root Causes

Root Cause 1 - The Request Type field is not set

For a Customer Notification to be sent from a JSM ticket, it is required that the Request Type field located in the Service project request panel is set to a value. If this field is set to no match as shown in the screenshot below, then this ticket will be considered as an "invalid JSM request".

In such case, the following will happen:

• the request will not be visible by the customer, from the customer portal view
• no Customer Notification will be sent at all from this request

Root Cause 2 - The customer unsubscribed from the JSM ticket

Users have the option to unsubscribe from a specific request to stop receiving Customer Notifications from it, via 2 different methods:

• Method 1: By clicking on the Do not notify me button from the request
  

• Method 2: By clicking on the "Turn off this request's notifications" link from the request
  
  

One way to check if a user unsubscribed from a request is to ask them to open this request from the portal view and check if the link Get notifications shows in the UI:

If that link is showing, then it means that this customer unsubscribed from that request.

Another way to check that is to run the following SQL query after replacing ABC and 123 with the issue key of the JSM ticket:

SELECT subs."ID", subs."ISSUE_ID", subs."SUBSCRIBED", app.lower_user_name
FROM "AO_54307E_SUBSCRIPTION" subs
join jiraissue ji on ji.id=subs."ISSUE_ID"
join project pr on ji.project=pr.id
join app_user app on app.user_key=subs."USER_KEY"
where pr.pkey = 'ABC' and ji.issuenum = 123;

According to the example of output below, we can see that the user with username julien2 unsubscribed from the JSM ticket SDBASIC-27, which explains why this user never receives any Customer Notification from this ticket:

Root Cause 3 - The Customer Notification is disabled in the project for some specific events

If you observe that only a specific type of Customer Notification (for example Request created, Public comment added, ...) is never sent to any user from any JSM ticket within the same project, then chances are that this type of notification is disabled for this project.

To check it, go to the page Project Settings > Customer Notifications, and verify if any type of Customer Notification is disabled. In the example below, we can see that the Customer Notification of type Public comment added  is disabled for the whole JSM project:

Root Cause 4 - The customer did not receive a notification from an internal update made to the ticket

It is important to note that Customers can only receive notifications from updates that are visible to them. In the 2 scenarios listed below, no customer notification will be sent:

• an internal comment was added by an agent to the request (the comment was added using the button Comment Internally)
  
• the status of the JSM ticket was changed via a transition, but the "customer visible" status did not change.
  • For example, let's assume that a Request Type is configured via the page Project Settings > Request Types so that both statuses "Waiting for support" and "Pending" show as "Waiting For Support" on the customer side, as shown in the screenshot below:
    
  • In such case, if a JSM ticket transitions from "Waiting for support" to "Pending", the Customer-visible status changed notification will not be sent, since from the customer's point of view, the status did not change (it is still "Waiting for support")

Root Cause 5 - The issue only happens with the Approval Required notification

If approvers of a JSM request do not receive a notification to let them know that the request is waiting for their approval, then there could be a wide range of reasons why this is happening. The most common reason is that the Approvers field was not set quickly enough before the request entered the status "Waiting for approval". This usually happens when the Approvers field is not set from the Customer Portal UI but from some script or automation.

To check the full list of root causes for the approval notifications not being sent, please refer to the KB article The Approval notification is not sent when a Service Management Request is waiting for an approval.

Root Cause 6 - The issue only happens with the Customer Satisfaction notification

If the only type of notification that is not sent is the Customer Satisfaction notification, then there could be various reasons why this notification is not sent. The most common one is a misconfiguration of the workflow transition which leads to resolving/closing the issue.

To check the full list of root causes for the customer satisfaction notifications not being sent, please refer to the KB article The Customer Satisfaction survey is not sent when a Service Management request is resolved.

Root Cause 7 - The issue only happens with the Request reopened/Request resolved notification

If you observe that the only customer notifications that are not sent are the ones of type Request reopened or Request resolved, then it is likely that the issue resides with the workflow transitions that reopen (or resolve) a request. The 2 types of customer notifications rely on the value of the Resolution field. If this field is not clear when an issue is reopened, or not set when an issue is resolved via a transition, then a customer notification will not be sent.

For more information about this root cause, please refer to the KB article Service Management Notifications not sent on Resolved or Reopened Requests.

Root Cause 8 - The issue only happens with the Request Created notification

If you observe that the only customer notifications that are not sent are the ones of type Request Created, then it is likely that the issue resides with the Create workflow transition.

To verify that this root cause is relevant:

• Navigate to Project Settings → Customer Notifications and click on Audit log, you are presented with the screen below. This means that the automation that sends these notifications is not being triggered:
  
• Navigate to Project Settings → Workflows and edit the workflows that you have associated with the project, in the Create transition, you should see the even in the Post Functions tab like:
  

If you have something other than Issue Created there, then this root cause is relevant.

To fix the notification, click in the pencil icon next to the post-function that fires the event, and choose the Issue Created event. Once you save and publish the workflow, run a test to see if the Customer Notifications are sent (which can also be verified in the Audit Logs from this notification).

Root Cause 9 - The issue only happens with transitions to a certain status

If no Customer Notification is sent only in the case where a JSM request is transitioned to a certain status, then it is possible that the transition is configured with an incorrect property, especially if the following error is found in the Jira application logs:

2016-03-04 07:09:45,794 http-nio-8128-exec-8 ERROR admin 429x1292x2 1q47jn1 172.22.65.249 /rest/api/2/issue/50700/comment [c.a.jira.workflow.OSWorkflowManager] Caught exception while attempting to perform action 851 from workflow 61100 on issue 'HELP-7856'
com.opensymphony.workflow.InvalidActionException: Action 851 is invalid
    at com.opensymphony.workflow.AbstractWorkflow.doAction(AbstractWorkflow.java:559)

For more information about this root cause, please refer to the KB article Jira Service Management don't trigger notification in certain status.

Root Cause 10 - The notification was not sent because the ticket update was made by a ScriptRunner Groovy script

When using 3rd party add-ons such as ScriptRunner for Jira to automatically add a comment to a JSM request or transition it to a new status, depending on how the script was implemented, the JSM notification module might not detect the event triggered from that update. As a result, no customer notification will be sent from that update.

If you observe that customer notifications are properly sent when updates are made to the request directly by a user (from the UI), but not sent when the same updates are added by a script, then this root cause is relevant.

In such case, we recommend you to reach out to the add-on support team since scripts coming from 3rd party add-ons fall outside of Atlassian Support's scope.

Root Cause 11 - There is some misconfiguration in the automation used behind the scene by the Customer Notification

JSM Customer Notifications are using the JSM Automation modules to be sent. Even if Customer Notifications are listed under Project Settings > Customer Notifications and not under Project Settings > Automation, they work like JSM automation behind the scene.

For example, to see how the Request created notification is configured, you can click on the Audit Log button next to it. After that, click on Show Details next to any execution of this notification, to see what it is doing. In the screenshot below, we can see that, out-of-the-box, this notification is triggered on the event Issue Created, does not have any IF condition required to be executed, and uses the action "Send email":

Normally, the configuration of any Customer Notification cannot be changed from the UI, since their configuration page is hidden. However, we have seen a situation where the configuration of the Request Created notification had been somehow tampered (either via direct database manipulation, or via a 3rd party add-on), as shown in the screenshot below:

As we can see in the screenshot above, there is an IF condition that somehow got inserted in the configuration of that notification. Since this IF condition does not make sense when a request is created, as the request status does not change in such case, the IF condition keeps failing with an ERROR, and the Request created notification is never sent from any JSM ticket in the project.

If you observe that the customer notification that is never sent belongs to a specific type, and if you see any error that keeps showing at each execution in the Audit Logs of this notification, then this root cause might be relevant. In this case, we advise to raise a support ticket via the Atlassian Support portal for further assistance.

Root Cause 12 - An incompatible language package was installed

Customer Notifications might fail to be sent from specific JSM projects, if a language package that is incompatible with the JSM version was installed.

To check if this root cause is relevant and how to fix the issue, please refer to the KB article Customer notifications not sent from some Jira Service Management projects due to installed translation packs.

Root Cause 13 - Some customer notification templates are pointing to the same lingo ID (database corruption issue)

If the 3rd party add-on Project Configurator was used to import Jira Service Management projects from one instance to another, this root cause might be relevant. This add-on is impacted by a bug (linked below) which is known to create duplicate lingo IDs when importing projects:

• https://appfire.atlassian.net/browse/PCSUP-3357

Normally, each customer notification should have its own set of templates for the languages added to the JSM project. Each notification template points to its own unique Lingo ID in the Jira Database. If 2 templates point to the same Lingo ID in the Database (due to database corruption), the following issues might be observed:

• updating a customer notification template might overwrite another template, as explained in the KB article Jira Service Management Customer notification rule is saving to the wrong rule

• specific types of customer notifications (for example: Request Created, Comment Added, etc...) will not work at all in specific projects

To verify if this Root Cause is relevant:

• Check if the 3rd party add-on Project Configurator was used to import Jira Service Management projects from one instance to another
• Check if the problem only impacts customer notifications from a specific project, and for a specific event (for example: Request Created, Comment Added, etc...)

• Run the SQL query below, and check if you can spot duplicate values in the LINGO_ID column:

  SELECT p.pkey, rs."ID" as "RULESET_ID", tacd."CONFIG_DATA_VALUE" AS "Lingo ID", tacd."ID" AS "THEN_ACT_CONF_DATA_ID", rr."NAME"
  FROM "AO_9B2E3B_RULESET" rs
  	JOIN "AO_9B2E3B_RULESET_REVISION" rr ON rs."ACTIVE_REVISION_ID" = rr."ID"
  	JOIN "AO_9B2E3B_RULE" r ON r."RULESET_REVISION_ID" = rr."ID"
  	JOIN "AO_9B2E3B_WHEN_HANDLER_CONFIG" whc ON whc."RULE_ID" = r."ID"
  	JOIN "AO_9B2E3B_IF_THEN" it ON it."RULE_ID" = r."ID"
      JOIN "AO_9B2E3B_RSETREV_PROJ_CONTEXT" pc ON rr."ID" = pc."RULESET_REVISION_ID"
      JOIN project p ON p.id = pc."PROJECT_ID"
  	LEFT JOIN "AO_9B2E3B_THEN_ACTION_CONFIG" tac ON tac."IF_THEN_ID" = it."ID"
  	LEFT JOIN "AO_9B2E3B_THEN_ACT_CONF_DATA" tacd ON tacd."THEN_ACTION_CONFIG_ID" = tac."ID"
  WHERE
  	tacd."CONFIG_DATA_KEY" = 'lingo'
  order by p.pkey, rs."ID";

• Check if you can spot the following error in the Jira logs

  2023-04-24 12:32:22,005+0000 PsmqAsyncExecutors-job:thread-97876 ERROR jrey@atlassian.com     [internal.automation.then.SendActionHelper] No content translation is available for the recipient.

If you confirm that this root cause is relevant, you will need to fix the database corruption by getting rid of the duplicate Lingo IDs. Please refer to the KB article Jira Service Management Customer notification rule is saving to the wrong rule for more information on how to do it.