Dynamic triggers
Dynamic Triggers start a Julian conversation automatically from a CRM field change, a product signal, a form submission, or an API call, and log it back.
Dynamic Triggers start a Julian conversation automatically from an external event — a CRM field change, a product signal, a form submission, or a direct API call — then log and sync the call back through your CRM or API. The point is to remove the delay between lead capture and conversation, which is where inbound conversion is won or lost.
This is the mechanism that makes speed to lead real. If Julian learns about a lead through a periodic sync, the response clock has already been running for minutes. A trigger fires on the event itself.
What can start a conversation
| Trigger source | Example |
|---|---|
| CRM field change | Lifecycle stage moves to a qualifying value; a lead is assigned |
| Product signal | A free-tier account crosses a usage threshold |
| Form submission | A demo request on a high-intent page |
| API call | Your own system decides this contact should be called now |
| Scheduled event | A renewal date approaching |
Worth wiring up
These are the triggers that tend to justify themselves quickly:
High-intent form submission
The canonical case. Fire on submission rather than waiting for a sync.
Product usage threshold
A free-tier account hitting a limit is the clearest expansion signal you'll get.
Support ticket indicating expansion
A customer asking about a capability they don't have is a sales conversation.
Renewal window opening
Predictable, schedulable, and routinely missed.
Stage change to Closed Lost
Queue the account for a revival play later. See playbooks.
Website visit on a pricing page
Pair with website visitor tracking.
Logging and sync
Triggers don't just start the call — the call is logged and synced back through your CRM or API automatically. That means the trigger, the conversation, and the outcome all land on the record without anyone logging anything.
Configuring
Define the event precisely
"Lifecycle stage changed to X" is a trigger. "The lead looks interested" is not.
Add guard conditions
Exclude existing customers, open opportunities, and owned accounts — the same exclusions your ICP uses.
Confirm consent before enabling a call trigger
An internal CRM change is not consent from the contact. See consent and calling compliance.
Set a rate limit or cooldown
So a noisy field or a bulk import can't fire thousands of calls.
Point it at the right call flow
A renewal trigger and a demo-request trigger need different objectives. See call flows.
Test with a single record first
Then a small batch. Then enable.
Add a cooldown before you enable any CRM-field trigger. A bulk data import or a workflow that touches many records at once will fire the trigger for every one of them. This is the single most likely way to generate a large volume of unwanted calls, and it is entirely preventable.
Building on the API
For triggers your CRM can't express, call the API directly. See webhooks and API — note the endpoint reference isn't published yet, so contact support for the current specification.