How to keep Zendesk ticket status in sync with Jira

Neither Zendesk nor Jira updates the other's status field automatically. Linking a ticket to an issue, whether by pasting a URL in a comment or using a marketplace app, tells you the two are related. It does not make "Solved" in Zendesk follow "Done" in Jira, or the reverse. To get that, you build it yourself. Set up a Zendesk trigger that fires a webhook when the ticket's status changes, and a Jira automation rule that fires a webhook back when the issue transitions, so each one updates the other system through its API.

That's a real, working setup, and support and engineering teams build it often enough that it's a recurring topic on the Make and n8n community forums. It's also two automations watching each other, which means the first bug you'll hit isn't a missing sync, it's an infinite one.

Why there's no native two-way sync

Zendesk's ticket status lives on the ticket. Jira's issue status lives on the issue. Nothing in either product's data model treats them as one value with two mirrors. They're two separate fields that happen to describe the same piece of work. A Make community thread opened with the same ask. The original poster, Tobias_Safaie, wrote, "When a Zendesk ticket is created it should be creating an 'issue' in Jira. Any subsequent changes should be synced." A Make moderator's reply was conditional, not a flat no. If no suitable blueprint turns up in Make's template library, the moderator wrote, "you can create it yourself." That's the state of it across every automation platform, not just Make. You're wiring two field values together, not turning on a setting.

Building the two triggers

The mechanism is the same in both directions. Each side needs a condition on its status field, a webhook, and an API call that writes into the other system's status field.

Zendesk to Jira. Zendesk's trigger conditions support a status field with is, is_not, less_than, and greater_than operators against new, open, pending, hold, solved, or closed, per the Zendesk conditions reference. Pair a condition like "Status is Solved" with the notification_webhook action, which the Zendesk actions reference describes as sending "a message to an active webhook," and the trigger fires an HTTP request carrying the ticket ID and new status to whatever URL you register, typically a small relay that calls Jira's transition API.

Jira to Zendesk. Jira automation's trigger list includes a rule that fires when a work item transitions from one status to another. Pair that with the "Send web request" action, which the Atlassian automation actions docs describe as sending "an outgoing web request to notify another system when a flow is run," pointed at your relay, which calls Zendesk's Update Ticket endpoint with the mapped status.

Two triggers, two webhooks, one small service in the middle translating "Solved" to "Done" and back. That's the whole mechanism, and it's exactly what people are asking for help building on the n8n forum, in one thread about updating Zendesk from Jira status changes and a follow-up troubleshooting the sync breaking on comments specifically.

The loop you have to guard against

Wire both directions and you've built a cycle. Zendesk fires on status change, which updates Jira, which fires Jira's own trigger, which updates Zendesk, which fires Zendesk's trigger again. A responder on the n8n thread, ihortom, named the problem directly, warning that bidirectional syncing "can create an endless loop when Zendesk sync to Jira causes the workflow to update Zendesk back."

The fix is a guard condition on each trigger. Only fire the Jira-to-Zendesk automation if the new status didn't originate from the last Zendesk-to-Jira write, tracked with a tag, a custom field, or a short cooldown window on the relay. It's a few extra lines of logic, and it's also the first thing that breaks when someone changes the automation six months later and doesn't remember why the guard is there.

A worked example

At Anchorline, a payments infrastructure company, Daniela Voss leads the support team and set up exactly this pair of automations last quarter after engineering kept asking "did the customer already get an update on this?"

Daniela, in the ticket: Customer's payout webhook has been failing intermittently since Tuesday. Filed as PAY-118 in Jira, tagging for sync.

The Zendesk trigger, watching for the jira-linked tag plus any status change (the same mechanism as the Status-is-Solved example above, applied to every state instead of one), fires on the next update and calls the relay, which writes a comment and status onto PAY-118. Three days later, an engineer moves PAY-118 to "Done." Jira's automation fires, calls the relay, and the relay calls Zendesk's ticket API to set the ticket to solved and post a public reply.

Automated reply on ticket #4821: This issue (PAY-118) has been resolved. If the webhook failures continue, please reply to reopen this ticket.

For six months, that's fine. Then an engineer manually reopens PAY-118 to fix a regression without touching Zendesk, because the customer already got a resolution message and reopening the ticket felt like the wrong move. Now Jira says "In Progress" and Zendesk says "Solved," and the automation, built around the tag-plus-cooldown guard, doesn't fire again until someone touches the status field directly. Daniela finds out from the customer, not from either system.

Where the two-webhook setup breaks down

The mechanics above hold for one ticket mapped to one issue with a status vocabulary that translates cleanly. Past that, the same gaps show up on most teams that build this:

• Status vocabularies don't line up one-to-one. Zendesk's six statuses and a Jira workflow's board columns rarely map evenly; someone has to decide what "Pending" on the customer side means when the Jira board has both "Blocked" and "Waiting on customer," and that mapping table needs maintaining as either workflow changes.
• One ticket, several issues. A ticket that spawns two Jira issues, or an issue that resolves three tickets at once, breaks the one-to-one assumption both trigger conditions are built on.
• Manual moves don't announce themselves. As in the example above, anyone dragging a card on the Jira board or changing a ticket's status by hand bypasses whatever "don't answer your own echo" guard you built, and the two systems drift silently until someone notices.
• The requester gets lost at the boundary. The relay passes a status value and an issue key. It generally doesn't carry who asked, which company they're at, or what they were told last, so a status update lands in Jira with none of the context a support-side reader would want.

None of that means don't build it. For a small, stable status vocabulary and a team that rarely files a ticket against more than one issue, the two-trigger setup above is a reasonable week of work and it'll run quietly for a long time.

Where Modem fits

We're describing Modem here because it's what we build and sell, not because it's neutral information, so read the framing with that bias in mind. Modem doesn't run a webhook relay between Zendesk and Jira. It captures Zendesk tickets directly, including status, and it monitors and can act on Jira issues in the projects you connect, including their status. Both land in the same topic, so a ticket and the issue it caused sit next to each other with their statuses visible together, instead of you checking two dashboards or trusting a relay's mapping table to have run correctly.

The requester problem above is what this closes. The person and company behind the ticket stay attached to the topic through the Jira issue's whole life, splits and re-parenting included, so when engineering asks "does anyone remember why we're doing this," or a PM wants to notify whoever's still waiting, the answer doesn't depend on a status field someone forgot to update by hand. There's more on how that context survives handoffs in our guide on seeing who actually asked for a Jira epic or story, and on the Zendesk side specifically in mining feedback from Zendesk tickets. Modem is one credible way to close this gap; it isn't the only one, and the two-trigger build above is a legitimate alternative if your setup stays small.

The smallest version to start with

Pick one direction first, not both. Set up the Zendesk trigger and webhook alone, watching for "Status is Solved" on tickets tagged with your Jira issue key, and let it write a comment (not a status change) onto the linked issue. That gets engineering the signal without any loop risk, since nothing on the Jira side writes back yet. Add the return direction, with its guard condition, only once the one-way version has run cleanly for a couple of weeks and you've seen what your real status vocabulary needs to map.