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, without a middleware box between Zendesk and the rest of the stack.

• One Zendesk subdomain per connection, with a sandbox instance for building and testing on Enterprise plans
• Reads ticket fields, forms, custom objects, and macros at connection time, so a mapping uses your own field names
• Triggers can be driven by a Zendesk trigger or automation, so admins decide exactly which tickets reach a flow
• Two-way sync flows carry a loop guard, so an update the connector made does not trigger itself back

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

• Give agents account context on every ticket.
• Escalate to engineering without losing the thread.
• Run a triage agent with a human check.

A real flow support teams turn on early, with the actual field-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 posts to the CSM before the ticket is picked up.

1. 1Trigger: a Zendesk trigger fires on Ticket is Created and calls Neblex, passing the ticket ID and the requester email.
2. 2Resolve account: search the CRM for a contact with that email, then read its parent account for tier, arr, csm_email, and renewal_date.
3. 3Branch, no match: if no account is found, tag the ticket unmatched-account and stop, leaving normal routing to handle it.
4. 4Stamp the ticket: Update 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. 5Alert: if arr is 100,000 or more, resolve the CSM's Slack user by csm_email and direct-message them the ticket link, subject, and renewal date.
6. 6Internal 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 under a loop guard. (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 spins up 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. Ticket fields, forms, and Zendesk custom objects are discovered at connection time.

Commonly used objects

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

Help Center articles are supported through a separate operation set, so a flow can publish or update knowledge base content alongside ticket work.

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

• OAuth 2.0 or API token. OAuth 2.0 for interactive setup, an email and API token pair for unattended connections. Both act as a specific agent.
• 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. A flow can expose a webhook endpoint for Zendesk to call, protected by an API consumer key with per-consumer rate limits, quotas, and metering.
• Full audit trail. Every ticket read, update, comment, and side conversation, with the ticket ID and payload, flows into the same Neblex audit trail as every other connector.

The shape of the vendor's limits, as published at the time of writing. Verify the exact figures for your plan; they change without notice. Neblex honors the vendor's own rate-limit and retry signals and backs off within them.

• 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 poll
• Exponential backoff and retry are applied automatically on 429 responses, honoring the Retry-After header