> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getswan.com/llms.txt
> Use this file to discover all available pages before exploring further.

# App event triggers

> Fire a trigger from an event in a connected third-party app, like a call recording being processed.

## What it does

Some [connected apps](../integrations/built-in-integrations) can fire a trigger directly off an event that happens inside them, without you building a raw webhook yourself. Swan wires up the connection on your behalf — a webhook it registers with the app, or a native app subscription — so you just pick the event you want and the trigger fires with structured, app-specific data already attached.

Whether an app supports this depends on the app: some only expose tools Swan can call (read data, take actions), while others also expose events Swan can react to. The set grows over time, so the current list is whatever shows an event option when you create a trigger (**[Triggers](https://agent.getswan.com/triggers) → New trigger**) — or just ask Swan "which apps can trigger an automation?" As of writing it spans roughly 19 apps, including CRMs (Salesforce, Pipedrive, Attio), meeting and call tools (Fathom, Fireflies, Zoom, Calendly, Google Calendar), Google Workspace (Docs, Sheets), support (Zendesk), and outbound/marketing tools (Instantly, ActiveCampaign, Mailchimp), among others like Airtable, Notion, Linear, Stripe, and Productboard.

## Filtering which events fire

An app event trigger can carry **event filters**: conditions on fields of the incoming event, combined with All (every condition must match) or Any (one match is enough) logic. You set them up when creating the trigger or later from its configuration card (open the trigger from [Triggers](https://agent.getswan.com/triggers), then Configure) — pick a field from the event's schema, an operator (equals, contains, greater than, exists, and so on), and a value. Fields inside lists work too (say, an attendee email on a calendar event), where each list entry is checked independently.

Events that don't match your filter are dropped before anything runs — they don't start a run, don't appear in run history, and don't cost any credits.

## Requirements

The app has to be connected to your organization first — connect it from [agent.getswan.com/tools](https://agent.getswan.com/tools) (see [connected apps](../integrations/built-in-integrations) for details). If the connection is lost later (an expired token, a revoked authorization), the trigger stops firing until you reconnect it.

## Cost

Each app event fires for 1 credit as a flat fee today, plus whatever the run's own actions cost. Some apps may define a different flat fee for their specific events. See [credits](../administration/credits) for how action costs are calculated.

## Common questions

**My app isn't listed as having event triggers — can I still react to it?**
If the app is connected but doesn't support event triggers directly, check whether it can send a webhook you point at a [webhook trigger](webhook) instead — many apps that lack native event support in Swan's catalog still have generic outgoing webhooks you can wire up yourself.

**Does disconnecting the app pause the trigger, or delete it?**
Disconnecting the app stops new events from arriving, but the trigger itself isn't deleted — reconnecting the app resumes it.

**Can one app event trigger cover multiple event types from the same app, like both "record created" and "record updated"?**
Each event type is its own trigger source — set up a separate trigger per event type you want to react to differently. Within one event type, use event filters to narrow which events actually fire the trigger.

**Do app event triggers show up differently in monitoring than webhook triggers?**
No — runs from app events appear alongside all your other trigger runs in [monitoring runs](monitoring-runs), tagged with the app they came from.