How to keep a record of every outgoing customer notification in JSM Cloud

[#1]

If you run a service desk, sooner or later someone asks: "Did the customer actually get our reply?" In Jira Service Management Cloud that is a surprisingly hard question to answer, because JSM keeps no queryable log of the notifications it sends. This post shows why the gap exists, what the native tooling can and cannot do, and what a retained outgoing log looks like in practice.

Why there is no outgoing log natively

JSM sends customer notifications constantly: a request is created, an agent posts a public reply, a status changes, and each of those fires an email to the reporter and request participants. What it does not do is keep a searchable, retained record that those notifications went out.

The one native artifact that looks like a log is the Customer Notification Log (Project settings > Customer notifications > Notification log). The detail that trips people up: it records only notifications that failed to send. A successful send leaves no entry at all. Useful as a bounce list, but it cannot tell you that a message did go out.

This is the substance of one of the highest-voted open requests on the JSM issue tracker, JSDCLOUD-4698 ("Provide an outgoing email logs"), open since 2012 with about 1,490 votes as of this writing. That vote count is worth pausing on: this is one of the most-requested pieces of missing visibility in the product.

What you can do with native tooling

• Customer Notification Log for failures. Check it first when a customer says they never got a reply. If the send failed, it is here with a reason. Treat it as your bounce list.
• Notification Helper (Project settings > Customer notifications). Point it at an issue and a recipient and it explains whether a notification would be sent and why. The right tool for "should this person have been notified?"
• Notification scheme review. When no one got it, the cause is often the scheme itself.

The honest limits: none of these give you a retained, searchable history of successful sends. For a one-off "why didn't this fire" they are enough. For "show me everything we sent on WEB-1423, and to whom," an SLA dispute, or a compliance review, there is nothing native to point at.

What a retained outgoing log looks like: Notification Log for JSM

Disclosure: I work for Katabarwa Labs, and we build a small app for exactly this gap, so treat this as one option among whatever you evaluate. Rather than describe it in the abstract, here is what answering "did the customer get it?" actually looks like.

Every notification-triggering event (request created, public reply, internal note, status change) is recorded the moment it fires, with the request, the service desk, who acted, and who received it. Not just the failures, everything:

When a specific ticket is disputed, you filter instead of investigating. Request key, service desk, customer versus internal audience, notification type:

History is kept for a retention window you control (months, not days), pruned automatically by a daily rollup, and the whole log exports as audit-ready CSV, one row per notification:

If you prefer watching to reading, this one minute demo walks the same flow end to end, from a notification firing to the CSV export:

https://youtu.be/IkUOh9VqfY0

It runs entirely on Atlassian Forge inside your own Jira Cloud tenant, so nothing leaves your instance, and it is read-only: it records and exports, and changes nothing in JSM or Jira. It records from install forward and does not backfill history from before install.

If the native failure log and Notification Helper cover your needs, use them. If you need a retained, searchable, exportable record of what actually went out: Notification Log for JSM on the Atlassian Marketplace

If the app is close but missing something your desk needs, tell us what that is and we will build it.