Zendesk (Two-Way)

Zendesk sends ticket webhooks to JAMS Incident Management, and JAMS calls / SMS-es / pushes your on-call team until someone responds. When they Acknowledge or Solve, JAMS writes the new status back into the Zendesk ticket and adds an internal note — so the ticket reflects who responded and how, without anyone double-bookkeeping. Zendesk tracks the work; JAMS makes sure a human actually picks up an urgent ticket.

Plan availability: The Zendesk integration is included on the Professional plan and up. See Plans & Billing.

Two directions. This page covers Zendesk → JAMS (an urgent ticket pages your on-call team). JAMS can also go the other way and open a brand-new Zendesk ticket from any other alert — see Open a Zendesk ticket from a JAMS alert near the bottom.

What you'll get

After setup:

An urgent Zendesk ticket is created → a Trigger fires a Webhook to JAMS → recipients get a call (and/or SMS/push/email/Teams/Slack per your flow)
Recipients press 1 to Acknowledge or 2 to Solve — or do nothing and escalation continues to the next person
Acknowledge sets the Zendesk ticket to Open; Solve sets it to Solved
A private (internal) comment is added to the ticket recording who acted and how
If the ticket is Solved or Closed directly in Zendesk, JAMS stops escalating automatically
The /incidents page shows everything in flight with one-click Acknowledge / Solve buttons

What you'll need

A Zendesk Support account (a sandbox / test instance is fine for trying it out).
An agent with permission to update tickets, plus an API token (Zendesk Admin Center → Apps and integrations → Zendesk API → Token access → Add API token). API token is the recommended auth; email/password (Basic) and a pre-issued OAuth token are also supported.
Admin access in Zendesk to create a Webhook and a Trigger.

Step 1 — Create the Zendesk connection in JAMS

The connection bundles your API credentials, the recipients, the escalation policy, and the per-flow webhook URL.

In JAMS, open Integrations → Zendesk from the sidebar.
Click Create a Zendesk Connection and fill in:
- Connection name — anything memorable (e.g. support-urgent).
- Subdomain — the part before .zendesk.com (e.g. acme for acme.zendesk.com).
- Authentication — API token (agent email + token) is recommended. Basic (email + password) and OAuth token are also available.
- Who gets notified — pick individuals, groups, or an on-call rotation, plus the channels (Call is the most reliable for urgent tickets).
- Escalation interval — how long to wait for each recipient to acknowledge before moving to the next.
Save Connection. JAMS shows you the webhook URL — it looks like https://<your-JAMS-backend-host>/api/zendesk/webhook/{tenantId}/{flowId}. Copy it; you'll paste it into Zendesk next.

The credentials are used only for write-back. Inbound tickets authenticate by the secret webhook URL itself, but pushing Acknowledge / Solve back into Zendesk requires the API credentials you entered here. With API token auth, JAMS sends the standard {agent-email}/token Basic header. Without working credentials, JAMS can still call your team — it just can't update the ticket.

Step 2 — Create the Webhook in Zendesk

In Zendesk, go to Admin Center → Apps and integrations → Webhooks → Create webhook.
Connect with: Trigger or automation.
Name: JAMS on-call.
Endpoint URL: paste the webhook URL from Step 1.
Request method: POST. Request format: JSON.
Authentication: None — the JAMS webhook URL is itself the secret.
Create webhook (you can use the Test button later, once the Trigger is built).

Step 3 — Create the Trigger that fires the webhook

This is what makes Zendesk tell JAMS "an urgent ticket just came in."

Go to Admin Center → Objects and rules → Business rules → Triggers → Create trigger.
Name: Notify JAMS on urgent.
Conditions → Meet ALL: add Ticket: Priority is Urgent (and optionally Ticket: Status is New, so you only page on brand-new urgent tickets).
Actions: add Notify by → Active webhook, choose the webhook from Step 2.
In the JSON body that appears, send the ticket fields. ticketId is required; the rest are recommended:

{
  "ticketId": "{{ticket.id}}",
  "subject": "{{ticket.title}}",
  "description": "{{ticket.description}}",
  "priority": "{{ticket.priority}}",
  "status": "{{ticket.status}}"
}

Create / Save.

ticketId is the numeric ticket id ({{ticket.id}}) — JAMS stores it when the webhook arrives so it can update the exact ticket later via the Zendesk REST API. Don't substitute the external id or a custom field.

Step 4 — Add close-sync (so JAMS stops when the ticket is solved)

Without this, someone solving the ticket inside Zendesk wouldn't stop JAMS from calling the on-call. Create a second Trigger:

Create trigger → Name: Tell JAMS ticket solved or closed.
Conditions → Meet ANY (not ALL — a ticket is never Solved and Closed at once):
- Ticket: Status is Solved
- Ticket: Status is Closed
- Ticket: Tags contains at least one of closed_by_merge
Actions: Notify by → Active webhook → the same webhook, with the same JSON body as Step 3.
Save.

Don't skip Closed. Merging a ticket into another closes it on the spot without ever passing through Solved, so a Solved-only Trigger never fires and JAMS keeps paging for a ticket that's already handled. Common with voicemail tickets, which are often merged into the caller's existing ticket.

JAMS treats an incoming status of solved or closed as "stop escalating" and cancels any pending notifications.

How the two-way flow works

Zendesk ticket created / updated (Priority: Urgent)
   │
   ▼
Trigger → Webhook POST → /api/zendesk/webhook/<tenant>/<flow>
   │
   ▼
JAMS creates Incident (stores ticket id) + fires flow notifications (call, SMS, push…)
   │
   ▼ recipient presses 1 / 2 (or clicks button on /incidents)
   │
   ▼
JAMS PUTs <subdomain>.zendesk.com/api/v2/tickets/<id>.json
                  { status: open | solved, comment: { body, public:false } }
   │
   ▼
Zendesk ticket reflects the new status + internal note
JAMS escalation stops (notifications cascade to "acknowledged")

When the call lands, after the ticket summary you'll hear:

"Press 1 or say acknowledge to acknowledge this ticket in Zendesk. Press 2 or say solve to solve it in Zendesk."

1 / "acknowledge" → Zendesk ticket → Open, with an internal note. (Zendesk has no "in progress" status; moving New → Open signals an agent is engaged.) Escalation stops; the ticket stays open.
2 / "solve" → Zendesk ticket → Solved, with an internal note. JAMS marks the incident resolved.

You can also press 3 to replay the message at any time.

Why Solved, not Closed? Zendesk closes solved tickets automatically after a set period, and its API generally won't let an integration set Closed directly. JAMS sets Solved, which is the correct agent-driven resolution state.

SMS replies

Reply to the alert SMS with 1 for Acknowledge or 2 for Solve. JAMS confirms with a short reply. Same Zendesk-side effect as the voice menu.

Teams / Slack / push

If your flow delivers to Teams or Slack, the alert card carries Acknowledge / Solve buttons that do the same write-back. Push and email deliver the alert and can acknowledge the JAMS escalation, but only the interactive channels (voice, SMS, WhatsApp, Teams, Slack, and the /incidents buttons) push status back into Zendesk.

/incidents page

Open /incidents. Zendesk tickets appear alongside other sources with Acknowledge and Solve buttons. Buttons hit the same backend code as the voice/SMS path — Zendesk stays in sync.

Auto-resolve

When Zendesk reports the ticket as Solved/Closed (via the close-sync Trigger from Step 4), JAMS:

Marks the incident resolved.
Cancels any queued/sent notifications in the same group (no more pages for a ticket that's already handled).
Logs zendesk.auto_resolved in the audit trail.

If the Trigger didn't fire (for example, an older Solved-only Trigger and a merged ticket), the next Acknowledge or Solve catches it: Zendesk refuses to update a Closed ticket, so JAMS closes the incident itself, stops the alerts, and tells the responder "That Zendesk ticket is already closed, so I closed it here and stopped the alerts." This is logged as zendesk.auto_closed_already_closed.

Force-close (orphan incidents only)

If an incident gets stuck because the Zendesk ticket behind it no longer exists (deleted, or a test payload), a normal Solve would try to PUT Zendesk and fail. For exactly these cases the /incidents page has a Force close button that marks the incident resolved on the JAMS side and cancels pending notifications without calling Zendesk. It's logged as zendesk.force_closed so it's distinguishable from a real solve.

Open a Zendesk ticket from a JAMS alert

Everything above is Zendesk → JAMS. JAMS can also go the other way: for alerts that didn't come from Zendesk — a JAMS job failure, an email / API / webhook alert, or a manual send — a recipient can open a new Zendesk ticket straight from the alert, without leaving the phone call or chat. Great for turning "something just broke" into a tracked ticket in one step.

Opening a ticket also acknowledges the alert. It's a single Create + Acknowledge action, so JAMS stops escalating the moment the responder files the ticket — no separate "press 1 to acknowledge" needed.

The new ticket is pre-filled from the alert:

From the alert	Zendesk ticket field
Title / flow name	Subject
Message body	First comment (internal)
Severity	Priority (Critical→Urgent, Error→High, Warning→Normal, Info→Low)

Because the new ticket is linked back to the alert, everything in How the two-way flow works then applies to it — a later Acknowledge/Solve keeps it in sync, and solving it inside Zendesk stops any remaining JAMS activity.

Turn it on (admin, once per flow)

Make sure a Zendesk connection exists (Step 1 above). The ticket is created with those credentials, so the agent needs permission to create tickets.
Open the flow you want — in New flow, Edit flow, or AI Helper.
In the flow's settings, tick "Let recipients open a ticket from this alert," choose Zendesk, and pick the connection. Save.

The option only appears when your plan includes Zendesk and a connection is configured. It isn't offered on Azure Monitor flows — those alerts are already tied to their own incident.

How a recipient opens one

However the alert reaches them, there's now one extra choice on the menu:

Voice call: the menu adds a "create ticket" option — press the number it announces, or say "create ticket."
SMS: reply with the digit shown next to "create ticket."
Teams / Slack: a Create Zendesk ticket button on the alert card.
Notifications page: a 🎫 Zendesk ticket button next to any active alert on /notifications.

JAMS confirms with the new ticket number — e.g. "Created Zendesk ticket #4821 and acknowledged the alert." Choosing it twice is safe: the second press just reports the ticket that's already open, never a duplicate.

Verify it works (end-to-end)

In Zendesk, create a new ticket with Priority = Urgent (matching your Trigger condition).
Within a few seconds, the on-call recipient should get a JAMS call / SMS / push.
Press 1 on the call (or reply 1). In Zendesk, open the ticket — Status should flip to Open and an internal note should appear.
Press 2 (or click Solve on /incidents) — the ticket moves to Solved.
Create another urgent ticket, then Solve it directly in Zendesk — JAMS should stop escalating within ~30 seconds.

Tip: Zendesk's webhook editor has a Test button (and an Activity log under the webhook) that shows the exact payload and the HTTP response from JAMS — invaluable when a Trigger isn't firing as expected.

Troubleshooting

Symptom	Likely cause	Fix
JAMS never calls	The Trigger didn't fire, or it isn't wired to the webhook	Confirm the Trigger conditions match your test ticket (Priority Urgent), and its action is Notify by → Active webhook pointing at the right webhook. Check the webhook's Activity log for delivery attempts.
Webhook Activity log shows a non-2xx from JAMS	Bad JSON body or missing `ticketId`	Make sure the body includes `"ticketId": "{{ticket.id}}"` and is valid JSON.
Calls land, but pressing 1 says "Zendesk refused our credentials."	Wrong agent email / API token, or token access disabled	Re-enter the email + API token in the Zendesk connection (Edit). Confirm Token access is enabled in Admin Center → Zendesk API.
Pressing 1 says "Our Zendesk account is not authorized to update this ticket."	The agent lacks permission to update tickets	Use an agent (not an end user / light agent) with ticket-edit rights.
Pressing 1 or 2 says "Zendesk rejected the update (…)"	Zendesk refused the change for the reason shown in brackets — usually a required field or ticket-form rule (Solve needs every field your account requires for Solved)	Fix the field named in the message on the ticket, or act from within Zendesk.
The responder hears "That Zendesk ticket is already closed, so I closed it here and stopped the alerts."	The ticket was Closed in Zendesk (often by a merge) and the close-sync Trigger didn't report it	Nothing to do for that incident. To stop the extra alerts next time, make sure the Step 4 Trigger fires on Closed and `closed_by_merge`, not just Solved.
Pressing 1 says "Zendesk no longer has this ticket."	The ticket id doesn't exist (deleted)	For a genuinely deleted ticket, use Force close on `/incidents`.
Calls keep coming after the ticket was solved, closed or merged in Zendesk	The close-sync Trigger (Step 4) isn't firing for that change	Confirm the Trigger uses Meet ANY with Solved, Closed and `closed_by_merge`, and notifies the same webhook with the same body.
"Create ticket" isn't offered on the alert	The flow's toggle is off, your plan doesn't include Zendesk, no connection is configured, or it's an Azure Monitor flow	Enable "Let recipients open a ticket from this alert" on the flow, confirm the plan and a saved connection. Azure Monitor flows don't support it.
"Create ticket" fails with "Zendesk connection not configured" or an authorization error	No usable connection, or the agent can't create tickets	Add/fix a Zendesk connection (Step 1) and use an agent with ticket-create rights.

If you hit something not on this list, capture the time of the failed call/SMS and a screenshot of the /incidents audit log (plus the webhook's Zendesk Activity entry), then reach out to support — that gives us enough to trace through the backend's [Zendesk] log lines.