What problem are we trying to solve?
When a ticket is escalated to Jira using the new Jira integration, which we had no choice but to switch to due to the deprecation of the previous integration, an automated comment is posted to the Zendesk ticket:
"This Ticket has been escalated to Jira {key}"
There is currently no way to suppress or disable this message. This is problematic because automated comments trigger webhook activity, and the comment itself pollutes ticket audit logs in ways that interfere with downstream workflows.
Additionally, the feature is inconsistently implemented: a comment is posted when a Jira ticket is linked, but no equivalent comment is posted when a Jira ticket is removed. This makes the feature incomplete and we as customers are absorbing the disruption of the notification without receiving the full informational value it could provide nor anyway to turn off the feature.
Who is impacted?
Customers who:
- Have migrated to the new Jira integration (we had no choice due to the deprecation of the old integration)
- Run comment-triggered webhooks
- Use ticket audit logs for operational purposes such as security monitoring or tag tracking
How is the problem handled today?
We have implemented a workaround via a Zendesk trigger that explicitly blocks the webhook from firing if this specific wording is found in the comment. However, this workaround introduces two ongoing problems:
- Audit log noise – In our integration we have flows that review all ticket audits for security purposes and to track tag changes. The escalation comment is being incorrectly flagged during this process, creating code overrides to ignore and review overhead.
- Latent risk of a feedback loop – The blocking trigger has no self-documenting context. If a future team member removes it without understanding why it exists, the webhook could begin firing on every Jira escalation comment — potentially causing a feedback loop between Zendesk and their external systems.
The current workaround is fragile, undiscoverable, and does not address the root cause.
What would a better experience look like?
A configuration option that allows customers to opt out of the automated escalation comment entirely. This could be a simple checkbox in the Jira integration settings such as
Why now?
As customers we are forced migrant to the new integration due to the deprecation of the old one.
The new integration introduced this behavior without a corresponding opt-out, and in its current state the feature is only half-implemented: it notifies on link but not on removal. The workaround in place is functional but fragile, and the risk of a feedback loop is a live operational concern.
What are the potential impacts or benefits?
- Eliminates audit log noise for customers using automated audit review workflows
- Removes the risk of accidental feedback loops caused by undocumented trigger workarounds
- Reduces friction for customers migrating from the legacy Jira integration
- Low implementation cost relative to the operational risk it mitigates
Anything else we should know?
After the integration calls POST /api/v2/integrations/jira/{{external_id}}/links, somewhere in the server-side flow there is most likely a PUT /api/v2/tickets/{{ticketId}} that adds the private comment or perhaps via your undocumented GraphQL endpoints, but either way the outcome is the same. What I'm requesting is not rocket science, but a conditional check before that call, gated by a boolean configuration option exposed in the integration settings UI.
In practical terms, this is a small, well-scoped change: a config flag on the backend, a corresponding toggle on the frontend, and a conditional check in the existing workflow. The development effort should be modest relative to the operational risk it resolves for affected customers.
