Zendesk connector

The Zendesk connector lets a Neblex workflow or agent act on support conversations: enrich a new ticket with account context, escalate to engineering and keep both sides in sync, run a triage agent that drafts a reply for review, or move ticket data into the warehouse.

• One Zendesk subdomain per connection, with a sandbox instance for building and testing on plans that include one
• List operations for ticket fields, forms, custom objects, and macros let a flow read your own field names when it needs them
• Flows start from a Zendesk trigger or automation that calls a Neblex Webhook trigger, so admins decide exactly which tickets reach a flow
• In a two-way sync, the flow checks a tag or the update's author so an update it made does not sync back

The three jobs this connector is picked for most often, and what each one gets you.

• Give agents account context on every ticket. New tickets are stamped with the customer's tier, value, and owner from the CRM, so the agent knows who they are helping.
• Escalate to engineering without losing the thread. A bug ticket opens a linked issue in the engineering tracker, and the fix status comes back to the ticket.
• Run a triage agent with a human check. An AI agent classifies the ticket and drafts a reply, and a person approves it before anything goes to the customer.

A real flow support teams turn on early, with the actual step-level detail.

Every new ticket stamped with the account tier, and top accounts alert the CSM

On ticket creation, Neblex looks up the requester's account in the CRM, writes the tier and owner onto the ticket, and for high-value accounts alerts the CSM before the ticket is picked up.

1. 1
   Trigger: a Zendesk trigger fires on Ticket is Created and calls a Neblex Webhook trigger with the ticket ID and the requester email.
2. 2
   Resolve account: search the CRM for a contact with that email, then read its parent account for tier, arr, csm_email, and renewal_date.
3. 3
   Branch, no match: if no account is found, tag the ticket unmatched-account and stop, leaving normal routing to handle it.
4. 4
   Stamp the ticket: update the ticket, mapping account.tier → custom_field_tier, account.arr → custom_field_arr, account.csm_email → custom_field_csm, and add a tag of tier-enterprise, tier-mid, or tier-smb.
5. 5
   Alert: if arr is 100,000 or more, find the CSM's Slack user by csm_email and direct-message them the ticket link, subject, and renewal date.
6. 6
   Internal note: add an internal note on the ticket recording what was matched, so the agent sees the context in the ticket itself.

Common patterns other teams start from with this connector.

• Two-way case sync. Tickets and Salesforce cases stay in step, with status, owner, and comments syncing both ways and a loop check in the flow. (Support and CRM)
• Bug escalation. A bug ticket opens a linked Jira issue with the customer detail, and the fix status flows back to the ticket and the requester. (Support and Eng)
• Escalation bridge. A high-priority ticket creates a Slack incident channel, invites the on-call and account team, and posts the ticket and account context. (Support ops)
• Support data to the warehouse. Ticket, comment, and satisfaction data loads into Snowflake through incremental export for support analytics. (Data)

Support objects are covered for read and write, including Zendesk custom objects and their records.

Commonly used objects

Ticket, Ticket Comment, Ticket Field, Ticket Form, User, Organization, Group, Macro, View, Trigger, Automation, SLA Policy, Custom Object, Tag, Brand

Custom ticket fields are read and written like any other field, and the custom object operations cover your own Zendesk objects and records.

The connection runs as a Zendesk agent, so it holds exactly that agent's role and access, and no more.

• OAuth access token or API token. Use an OAuth access token, or an agent's email with an API token. Both act as a specific agent, and the credentials are stored encrypted.
• Role and group scoped. Use a purpose-built agent role with access to only the groups and brands the flows need, rather than an admin account.
• Webhook endpoints. When a Zendesk webhook calls a Neblex Webhook trigger, use Basic or a header secret, which Zendesk webhooks can send.
• Run history. Every run shows each step's status and errors; record data from successful runs is kept when the flow is set to keep run data for replay.

The shape of Zendesk's limits, as published at the time of writing. Verify the exact figures for your plan; they change without notice.

• Rate limits vary by plan, from a few hundred to over 700 requests per minute, with ticket create and update on tighter per-endpoint limits
• The Search API returns up to 100 results per page and 1,000 results per query, so a broad search must be narrowed with filters
• Incremental export returns up to 1,000 records per page and is rate limited to about 10 requests per minute
• Bulk ticket updates process up to 100 tickets per job, run asynchronously, with a job status to check
• Rate-limited reads and updates are retried with backoff, honoring the Retry-After header; ticket creates are POST calls, so turn on Retry on failure or an idempotency key for those steps