Approval Notification Not Sent for Pending Service Requests in JSM DC

Summary

When a Service Management request transitions to an approval status, the approval notification is not sent to the approver(s), although it should.

Environment

• Jira Service Management Data Center on any version from 3.0.0

• The request is using a workflow with an approval status

Expected behavior

A customer notification of type Approval Required should be sent to all the approvers defined in the request:

Solutions

This can happen due to different reasons. Please follow the steps below to resolve the issue:

The customer notification of type Approval Required is disabled

1. Navigate to Project Settings > Customer Notifications within the Service Management project.

2. Check the notification Approval Required.

3. Enable the Approval Required type notification if it is disabled.

The Approvers field does not match the field defined in the workflow's approval status.

1. Navigate to Project Settings > Workflows and select Edit for the Workflow in question.

2. Select the Status that requires approval.

3. Choose Configure next to the Add Approval.

4. Note the field used for Get Approvers from:

   

5. Make sure that the Approvers field used in the Approval status configuration is the same field used to set the list of approver(s) during the request creation.

   It is possible that you have duplicate fields with the same name, Approvers.

   Check this by looking for this field in Administration ⚙ > Issues > Custom fields, and ensuring that there is only one custom field with that name.

The Customer Request Type field was not set before the request transitioned to the status that requires approval.

1. The Customer Request type field must be set before the request enters the approval status for the approval notification to be sent.

2. If a request is created via the Create button from Jira UI, and not from the Customer Portal, the Customer Request type field will not be automatically set, and the approval notification will not be sent.

3. Make sure that the Customer Request Type field is always set before the request enters the Approval status (by ensuring that the request is created from the portal instead of from the Jira UI).

A post function by a third-party app, such as a Groovy Script, that changes the issue before the transition "Set issue status to the linked status of the destination workflow step.”

1. The post-function is causing a race condition, which prevents the approval system from identifying that an issue has an approval requirement.

2. Move the third-party post function to the bottom of the transition list.

The Approvers field was not set before the request transitioned to the status that requires approval.

1. The Approvers field must be set before the request enters the approval status for the approval notification to be sent.

   • Check the ticket's history to see if the Approvers field was set before the issue transitioned to the Approval status.

   • Check the post-functions from the transition that directs to the Approval Status.

     • If the Approvers field is set via a third-party app post-function or script, there is a chance that, due to some race condition, it won't be set "on time" (before the request enters the approval status).

     • In such a case, you might notice that the approval notification might be sent randomly or not.

2. Make sure that the Approvers field is always set before the request enters the Approval status:

   • If the Approvers field is set manually in the UI, make sure that this field is set either at the request creation or while the request is in a status located before the status with approval.

   • If the Approvers field is set via a 3rd party post-function, one way to ensure that this field is set early enough (before the request enters the status with approval) is to:

     • Add an intermediate status in the workflow (let's call it "intermediate" status).

     • Add a transition from the issue creation to the intermediate status, and move the third-party app post-function there.

     • Add a transition that connects from the intermediate status to the approval status.

     • Optional: Create a Service Desk automation rule (via Project Settings > Automation) that will automatically transition any ticket from the "intermediate" status to the “with approval" status.

The request is transitioned a second time to the same status that requires approval (JSM versions up to 4.18.x only)

1. The approval notification is only sent the first time the issue transitions to the approval status. If there is a transition configured to re-enter this status, then no approval notification will be sent. This is caused by JSDSERVER-6080 - Approval notifications are not sent if the approval is re-triggered through workflow transition.

2. Upgrade to JSM 4.19.x or later, as this was fixed in JSM 4.19.0.

The post-function Set issue status to the linked status of the destination workflow step is missing from the transition going to the Approval status.

1. Check the post-functions from the transition that connects to the Approval Status.

2. If you see that the Set issue status to the linked status of the destination workflow step post-function is missing, then it's probably the reason why the approval notification is not sent.

3. Add Update Issue Status (Sets issue status to the linked status of the destination workflow step) to the list of post-functions:

   • The transition should now contain the Set issue status to the linked status of the destination workflow step post-function.

A Script coming from a third-party app (such as ScriptRunner) sets the shouldSendMail flag to false, preventing the Approval Required customer notification from being sent.

1. Access the Audit Log page from the Approval Required notification (via the Project Settings > Approval Required page).

   • Check if the automation was triggered for the problematic issue key.

   • If it was triggered, check if the Send email action was successfully executed (with a green ✔️ icon).

   • If the action was successfully executed but the approval notification was not sent, move on to the next step below.

2. Replicate the issue by following the steps below:

   1. Go to the page ⚙ > System > Logging and Profiling.

   2. Click on Configure logging level for another package and add the package com.atlassian.servicedesk.plugins.automation with the option DEBUG.

   3. Replicate the issue.

   4. Check the Jira application logs (atlassian-jira.log file) and look for a line similar to the one below. Check the flag shouldSendMail in the Rule message data. If it is set to false, then this Root Cause might be relevant and move on to the next step below.

      2023-02-23 15:44:48,869+0100 PsmqAsyncExecutors-job:thread-1853 DEBUG admin 944x128585x1 gq57f3 XX.X.XXX.XXX /servicedesk/customer/portal/4/create/109 [c.a.s.p.a.i.e.engine.process.ExecutionJobProcessorImpl] Executing rule with the 'admin' user with the following rule message: RuleMessageImpl{data={newApproversKeys=["JIRAUSER10000"], issueId=10000, issueKey=ABC-123, shouldSendMail=false, currentUserUserKey=JIRAUSER10000, eventTimeKey=1677163488797, projectId=10100, inCustomerContext=true, ruleSetId=51}}

3. Check if there is a ScriptRunner script that is executed when the request that requires approval is created.

   1. Check the post-functions from the transition that connects to the Approval Status (usually it is the Create issue transition from the approval workflow).

      1. If you find a ScriptRunner post-function that is updating the issue, try to disable it and see if the problem goes away.

   2. Go to the page ⚙ > Manage Apps > ScriptRunner, click on the Listeners tab.

      1. Check if you see a script that is executed on the Issue Created event.

      2. If you find one, try to disable it and see if the problem goes away.

   3. If you did not identify any problematic script, disable the ScriptRunner app and check if the problem goes away:

      1. Schedule a maintenance window.

      2. Go to the page ⚙ > Manage Apps > Manage Apps.

      3. Disable ScriptRunner and check if the problem goes away.

      4. Re-enable ScriptRunner.

4. Disable the problematic ScriptRunner scripts identified during the steps above

   1. Reach out to the ScriptRunner support team for assistance (ScriptRunner scripts are not supported by Atlassian).

If the problem persists or if the above doesn’t lead to any possible solution, please contact Atlassian Support at https://support.atlassian.com/.