Configuring Triggers
Wire a connector event to a Shared Skill so the workspace drafts work automatically.
A trigger is the small rule that says "when this event happens in this source, run this Skill as this owner." Without triggers, connectors collect events that go nowhere. With triggers, the workspace becomes proactive.
This guide assumes you've already connected a data source and published the Skill you want to fire.
The Anatomy of a Trigger
Every trigger has five parts:
| Part | What it specifies |
|---|---|
| Source | Which connector (Slack, Drive, Confluence, Jira, Notion, SF, HubSpot, Gmail, Loom) |
| Event | Which event type from that source (new email, deal stage change, meeting scheduled) |
| Filter | Conditions that narrow which events match (label, channel, property, value) |
| Skill | Which published Shared Skill runs when an event matches |
| Owner | Whose authority the Skill runs under, and whose Inbox/Outbox it lands in |
Authoring a Trigger
- Open the workspace → Skills tab → pick the Skill you want to trigger.
- Click Add Trigger.
- Pick Source and Event from the drop-downs (only connected sources appear).
- Add Filter conditions — for example, only emails labeled
vendor-inbound, only deals moving toNegotiation, only Jira issues taggedurgent. - Set the Owner — defaults to you; for shared Skills, pick a team alias or a specific teammate.
- Click Test trigger to dry-run against a recent event without producing a draft.
- Save.
The trigger is live immediately. Future matching events will fire the Skill and land drafts in the configured owner's Inbox.
A Concrete Example
Say a sales team wants their /qbr-prep Skill to fire whenever a calendar event titled "QBR" lands within the next two weeks.
Source: Calendar
Event: Meeting scheduled
Filter: title contains "QBR" AND starts_within "14 days"
Skill: /qbr-prep
Owner: Alex Chen
Deliver: Inbox
Now, the moment a QBR meeting hits Alex's calendar, the workspace assembles the brief: pulls the account record from CRM, the last QBR notes from the doc store, the open tickets for the customer, drafts the deck outline. It's waiting in Alex's Inbox before they even know the meeting was booked.
Filter Patterns That Work Well
| Pattern | Why it's useful |
|---|---|
| Single label or tag | Tight, predictable, easy to debug |
| Property equals specific value | Stage transitions, status changes, owner reassignments |
Time-windowed (within N days) | Catches things while they're still actionable |
Combined with AND | Higher precision; fewer false fires |
OR across labels | Useful for cross-team aliases (vendor-inbound OR procurement) |
Avoid filter rules that match too broadly. A Skill that fires on every email in your Inbox will quickly become noise; one that fires on only labeled high-signal events stays trustworthy.
Testing and Iteration
The Test trigger action runs the Skill against the most recent matching event without producing a real output. Use it whenever you change the filter or update the Skill — it's the cheapest way to confirm the trigger still does what you expect.
You can also see every recent firing in Skills → skill detail → Trigger History. Each entry shows the source event, what matched, which version of the Skill ran, and what the resulting Inbox / Outbox item was.
Disabling and Editing
To pause a trigger without deleting it, toggle its Active switch. To change filter conditions, edit and save — changes apply to future events only, not to drafts already in the workspace.
When the underlying Skill is updated, triggers continue to point at the current published version automatically.
Related
- Connectors concept — how events flow into the workspace
- Connecting a Data Source — prerequisite for any trigger
- Shared Skills — what gets run when a trigger fires
- Agent Workspace — where triggered drafts land