Triggers and events
A connection says you may reach this tool. A trigger says tell me when this happens. Nothing flows until the second one exists.
Connected sources
Where it lands
Your workspace event log
normalized · evidenced · taint-classified
Subscribing
Console → Connectors, one connection open with its available triggers listed and two enabled
screenshot slot, save as public/screens/…png and set src
Choose few, deliberately
Every available trigger is not a good idea. Ingesting everything a tool emits produces a firehose in which decisions are harder to find, not easier, and it spends your governed-action and history budget on noise.
A useful rule: subscribe to the events where a decision might be visible.
| Tool | Usually worth it | Usually not |
|---|---|---|
| Slack | Messages in channels where work is discussed | Reactions, presence, typing |
| GitHub | PR opened/merged, issue opened, release published | Every push, every star |
| Jira / Linear | Issue created, status changed, comment added | Field-level edits |
| Notion / Docs | Page published or substantially updated | Every keystroke-level revision |
Start narrow. Adding a trigger later is one call; removing months of noise is not.
Where an event lands
Every trigger delivery arrives at one inbound webhook, is verified once, and is normalized into the same source event shape: source type, permalink, author, trust, content, timestamp, taint.
From there it is:
- appended to the workspace's event log;
- indexed for search;
- available to extraction as raw material;
- shown in Activity and the timeline.
What decides taint
Two checks, in order.
The author. Resolves to a known person in this workspace → trusted. Unrecognised or absent → tainted. Always a lookup, never an assumption.
The source type. Third-party by nature, documents, email, chat outside your boundary, stays tainted whoever forwarded it.
See Trust, taint and provenance.
Rate limiting
Inbound webhook traffic is rate limited per workspace. A tool having a bad day cannot exhaust the ingestion path for every other workspace.
When deliveries fail
Nothing is silently dropped. A trigger whose deliveries are failing is listed under Connectors → the connection → Failed deliveries, with the reason and the attempt count.
That list is the difference between "quiet because nothing happened" and "quiet because everything is broken", and it is worth checking before you go looking for the problem inside the tool itself.
Triggers versus outbound subscriptions
Two similarly named things pointing opposite ways:
Which one
Trigger
Subscription
Outbound is covered in Notifications.