Event Triggers
Run an agent automatically when something happens in one of your other systems — a Jira ticket is created, a GitHub PR is opened, a Salesforce opportunity changes stage. Event triggers are the webhook counterpart to scheduled automations and the perfect tool for in-line response to enterprise events.
Supported providers
| Provider | Common events |
|---|---|
| Jira | issue created / updated / commented |
| Zendesk | ticket created / updated / replied |
| GitHub | issues, pull requests, commit / push events |
| Confluence | page created / updated, comment added |
| Salesforce | record changes (opportunities, leads, cases) |
| HubSpot | contact / company / deal / ticket events |
Each provider sends its native payload — ZenSearch normalizes the parts the agent needs (subject, body, actor, links) and surfaces the raw payload to the agent if it asks for it.
Configuring an event trigger
In the dashboard:
- Create an Event Subscription for the team. Pick the provider and give the subscription a name.
- Copy the generated webhook URL and signing secret. The signing secret is only shown once at creation — if you lose it, rotate the subscription to get a new one.
- Paste the URL and secret into the source platform's webhook configuration (Jira → System → WebHooks; GitHub → Repo Settings → Webhooks; etc.).
- Create an automation with Event as the trigger type, link it to this subscription, and add any per-event filters (e.g., only fire on
issue.created, not on every comment). - Pick a delivery method — webhook, Slack, or email — for the agent's result.
What the agent sees
The agent receives a structured task packet describing the event:
- The event type and provider
- A normalized subject and body
- The actor (who triggered it) and timestamp
- A link back to the source record
- The raw provider payload, if the agent's prompt asks for it
This means an agent prompt as simple as "Summarize the customer's reported issue and find related runbooks" will work across providers without per-provider code in the prompt.
Webhook security
- Every inbound webhook is signature-verified with the per-subscription secret using each provider's native scheme.
- Mismatched signatures are rejected without invoking the agent.
- Replay protection: each event is deduplicated by the provider's event ID.
- Rotating the secret invalidates the old one immediately — useful if the source platform's webhook history may have been exposed.
Limits and behavior
- Per-team subscriptions: each subscription is scoped to a single team; cross-team event routing is not supported.
- Payload size: providers' native limits apply (Jira ~250 KB, GitHub ~25 MB). Anything beyond is dropped with a logged reason.
- Bursts: high-frequency events (e.g., a 5,000-issue bulk reassign) are rate-limited at the inbound edge to protect agent capacity. Excess events are dead-lettered with a visible reason.
- No outbound replies: ZenSearch does not write back to the source platform on its own. To do that, give the agent the appropriate agent tool integration and let it call the API.
Best practices
- Use shadow mode when wiring a new event subscription so production traffic doesn't immediately hit a half-tuned prompt.
- Filter events at the source (most providers let you scope webhooks by project / repo / record type) rather than relying on ZenSearch-side filtering — this keeps inbound noise low.
- Pair an event trigger with a human approval step if the agent will take any non-reversible action.
- Keep the signing secret in a secret manager, not in the source platform's plaintext config field where possible.