Skip to main content

​
What a trigger is made of

Every trigger has four parts:
  • Instructions — the playbook Swan follows every time the trigger fires. This is the same kind of instruction you’d type in chat, written once and reused for every event.
  • Toolkits — the set of tools Swan is allowed to use while carrying out those instructions (CRM actions, enrichment, outreach, and so on).
  • A source — the trigger type, which determines what kind of event starts a run. See the other pages in this section for the available sources (schedule, webhook, app events, HubSpot workflow, LinkedIn engagement, business events, Bombora intent, Website Changes, website visitors, and message received — the reply trigger created for you when you connect a sending account).
  • Enabled or disabled — a trigger only fires while it’s enabled. Disabling it stops new runs without deleting the trigger or its history.
You can also tag triggers with free-form labels to organize them (add or remove tags directly from a trigger’s row on Triggers), and a trigger can be scoped to just you (a personal trigger) or shared across your organization — pick which from the New trigger dropdown on that same page.

​
Choosing toolkits and connected accounts

The toolkits attached to a trigger are available to that trigger’s unattended runs. Email and LinkedIn toolkits are personal because they operate through a specific member’s connected account. When an Admin asks Swan to create or edit an organization-wide trigger, Swan can list the connected Email and LinkedIn toolkits owned by other active members of the org, labeled with each owner’s name. The Admin can attach those toolkits so the trigger can use that member’s account when it runs. This is limited to organization-wide triggers. It does not make the teammate’s Email or LinkedIn toolkit available in the Admin’s current chat, and Members and Viewers cannot see or select another member’s personal toolkits. A personal trigger can use org-shared integrations and its owner’s personal integrations, but not another member’s. These personal toolkits are for direct Email or LinkedIn actions performed by the trigger. Email and LinkedIn accounts used as senders in outreach sequences are selected separately; see senders and connected accounts.

​
From fire to run

Every time a trigger’s source produces a qualifying event, Swan records that event and starts a fresh agent run that follows the trigger’s instructions. Each run is independent — it doesn’t carry over memory or state from a previous run of the same trigger, aside from anything Swan has saved to org knowledge or memory. Website Changes has an extra qualification stage: Swan records each provider-matched company check, then classifies only a new provider-reported change against your filter. Missing, unchanged, excluded, and filtered-out checks do not start the downstream agent run.

​
Credits

Before starting any run, Swan checks that your organization has at least 10 credits remaining. If you have fewer than 10:
  • The run is blocked and doesn’t execute.
  • The trigger itself is not disabled or paused — it keeps listening for new events.
  • As soon as at least 10 credits are available again (for example, after your plan renews or you add more), the next event the trigger receives runs normally. Events that fired while your balance was below the threshold don’t get retried automatically once credits return — the run for that specific event is simply skipped.
Most trigger sources have a flat per-event fee, typically 1–2 credits, charged when the event is processed — on top of that, the run itself spends credits on whatever actions it takes (enrichment, sending messages, CRM writes, and so on). Website Changes instead costs 1 credit when a new provider-reported change is classified, whether it matches or is filtered out; quiet and skipped checks are free. That classification happens before the 10-credit check for a matched downstream agent run. See credits for how action costs work.

​
Who can create and edit triggers

Only organization Admins can create, edit, or delete triggers; Members and Viewers can view triggers but not change them. These permissions are fixed by role; see roles and permissions. There’s no way to manually fire an existing trigger on demand outside of its normal source — if you want Swan to do the same work right now, ask it directly in chat, or (for webhook triggers) send a test request to the trigger’s URL.

​
Testing before you turn a trigger on

Before enabling a trigger, you can ask Swan to simulate it against a hypothetical scenario — for example, “simulate this trigger for a CFO at a 500-person SaaS company who just raised funding.” Swan runs a read-only pass using the trigger’s instructions and your organization’s context (ICP, skills, CRM data) and returns what it predicts it would do, step by step, without actually taking any action or spending action credits. This is a good way to catch instructions that are ambiguous or would do something unexpected before real events start flowing through it. Simulation starts from a hypothetical trigger event; it does not test the source system itself. In particular, a Website Changes simulation does not call the provider or production classifier, so validate detection with a narrow live pilot.

​
Common questions

Can I pause a trigger without deleting it? Yes — disable it, either from the toggle on its row in Triggers or from the Active/Disabled toggle at the top of the trigger’s own page. Disabled triggers keep their configuration and history; they just stop starting new runs until you re-enable them. What happens to events that arrive while a trigger is disabled? They aren’t processed and aren’t queued for later — a disabled trigger simply isn’t listening. Can members create their own personal triggers? No. Creating a personal trigger requires the Admin role, just like creating an organization-wide trigger. Does simulating a trigger cost credits? No — simulations use read-only tools and don’t spend the action credits a real run would.