Flag related Zendesk tickets when incident.io declares an incident

Build me an agent workflow that triages my Zendesk support queue whenever a new customer-impacting incident is declared in incident.io, so my support reps are never blindsided.

Trigger: poll incident.io on a short schedule (every couple of minutes) using List Incidents, filtered to newly active customer-impacting incidents that the agent has not already processed. If incident.io webhooks are easier to wire up for new incidents, use that instead. Either way, only act on incidents flagged as customer-impacting.

For each new incident, the agent should:

1. Call Show Incident on incident.io to read the full details: summary, severity, affected products, status, and the current customer-facing message.

2. Use Search Tickets in Zendesk to find open tickets that plausibly relate to the incident. Match on the affected product tag, ticket activity in a recent window (default 72 hours), and meaningful keywords pulled from the incident summary. Skip closed and archived tickets.

3. For each matched ticket, call Update Ticket to do two things: (a) add an internal note (never a public reply) containing a link to the incident.io incident, a short brief of what is known, and a one-click-ready suggested reply the support rep can send to the customer; (b) add a tag of the form incident-<incident_id> so we can see at a glance which tickets are linked and so a re-run never double-posts.

4. After processing all matched tickets, call Send a Message via the Slack Bot integration to post a tidy brief in the support team's Slack channel: the incident link, severity, affected products, count of tickets flagged, and a bulleted list of permalinks to each flagged ticket. Use Slack mrkdwn formatting.

Guardrails the agent must follow:

- Internal notes only. The agent must never post a public reply on a Zendesk ticket. If the Update Ticket call would produce a public comment, do not send it.

- One canonical incident tag per ticket per incident. Before adding the note, check the ticket's existing tags. If the incident-<incident_id> tag is already present, skip that ticket so re-runs do not spam.

- Customer-impacting only. Ignore incidents that are not flagged as customer-impacting so internal-only issues do not pollute the support queue.

- One Slack message per incident. If the agent has already posted about this incident, do not post again unless the severity changed.

Use the Slack Bot integration (slackbot) for the Slack post, not the user OAuth Slack integration, since this is automated workspace messaging.