Route Zendesk Ticket Alerts to Microsoft Teams with ProxyHook

Zendesk is where support tickets live, but it isn't where most of your company works. Engineers, account managers, and on-call staff live in Microsoft Teams. A ticket can sit untouched for twenty minutes past its SLA before anyone outside the support queue even knows it exists, because checking Zendesk isn't part of their normal workflow.

ProxyHook closes that gap without asking anyone to change tools. Zendesk already supports outbound webhooks tied to its trigger system, so pointing one at a ProxyHook Source and routing to a Microsoft Teams Destination gets ticket activity into the channel people are already watching.

What Actually Fires the Webhook

Zendesk doesn't push every ticket event by default. A webhook only fires when a Zendesk trigger or automation is configured to call it, and those triggers run on conditions you define, such as "ticket status changed" or "ticket priority is Urgent." This matters for how you design the flow: the filtering starts on the Zendesk side, before ProxyHook ever sees the event.

A ticket-created payload posted to the webhook looks roughly like this:

{
  "ticket": {
    "id": 48213,
    "subject": "Checkout fails on mobile Safari",
    "priority": "urgent",
    "status": "open",
    "requester_email": "[email protected]"
  }
}

The exact fields depend on how the trigger's webhook action is configured in Zendesk, but priority and status are the two you'll want available downstream for filtering.

How to Wire Zendesk to Microsoft Teams

1. Create a Zendesk Source

In your ProxyHook dashboard, create a new Source and select Zendesk. You'll get a unique endpoint:

https://go.proxyhook.com/A817GH

ProxyHook responds with a 200 immediately on every request, so a delay on the Teams side never causes Zendesk to flag the webhook as unreliable or disable it.

2. Create the Webhook in Zendesk

In Zendesk, go to Admin Center > Apps and integrations > Actions and webhooks > Webhooks, and click Create webhook. Give it a name, paste the ProxyHook Source URL into the Endpoint URL field, set the Request Method to POST, and set the Request Format to JSON. Save it, then connect it to the trigger or automation covering the events you want to monitor, such as new ticket creation or a priority change.

3. Create a Microsoft Teams Destination

In the Teams channel you want alerts posted to, click the more options menu, choose Manage Channel, and open Connectors. Search for and add Incoming Webhook, give it a name, and copy the URL it generates. Back in ProxyHook, add a new Destination, select Microsoft Teams, and paste that URL in.

4. Build the Automation

From the Automations tab, create a new Automation, pick your Zendesk Source, and add the Microsoft Teams Destination. Save it and ticket events start posting to the channel as soon as the next trigger fires in Zendesk.

Filtering So the Channel Doesn't Become Noise

If your Zendesk trigger fires on every ticket status change so you don't have to maintain a dozen narrow triggers, you'll flood the Teams channel with routine updates nobody needs to see in chat. Add a Payload Contents filter between the Source and the Teams Destination to narrow it down:

• Key: ticket.priority
• Condition: equals
• Value: urgent

Only urgent tickets post to the channel. If your team also wants visibility into ticket volume without the interruption, add a second Microsoft Teams Destination in the same Automation pointed at a different channel, with no filter attached, so every ticket lands there while only the urgent ones interrupt the main channel.

Confirming Alerts Actually Post

Two views tell you where a ticket update is stuck if the Teams channel goes quiet. The Source's Logs view captures every raw request that hit the ProxyHook endpoint, including headers and body, so you can confirm Zendesk actually fired the webhook for a given ticket. No matching entry in the time window means the problem is on the Zendesk side, most often a trigger condition that didn't match or a webhook that got disconnected from its trigger during an edit.

If the request did arrive, the Automation's Logs view shows the payload ProxyHook sent to the Teams Destination and the response Teams returned. A non-2XX response here usually means the Incoming Webhook connector URL was regenerated or removed on the Teams side, which happens if someone edits the connector instead of just renaming it. You can replay any logged event from either view, which is the fastest way to confirm a filter change is working: find an urgent ticket you've already received, replay it after adjusting the ticket.priority filter, and check that it posts (or doesn't) as expected without waiting for a real ticket to match.

Get Started

Create a Zendesk Source in ProxyHook, add a webhook in Zendesk's Admin Center pointed at that Source's endpoint and connected to the trigger you care about, add a Microsoft Teams Destination using an Incoming Webhook connector URL from your channel, and connect the two with an Automation. Filter to ticket.priority equals urgent if you only want the interruptions that matter, and your support queue stops being a tab someone has to remember to check.

View the Zendesk integration | View the Microsoft Teams integration