AutomationWorkflows
Small, real, and on the record. Three triggers that matter, six actions that write real records, and a run history honest enough to debug from.
What fires, and what runs. The live set: no roadmap padding.
- Triggers
- A lifecycle stage changes
- A transaction is recorded
- An engagement threshold is crossed
- Actions
- Set a field
- Move to a lifecycle stage
- Create a custom object record
- Call a webhook
- Emit an engagement
- Create an activity
Fire on the moment. Not on the state.
A workflow listens for one of three real triggers, checks the condition you set, and runs on the crossing only, never again while it stays crossed.
- A stage changes, a transaction lands, a score crosses a line
- Crossing fires once: no re-fire while it stays crossed
- One condition if you want one: eight ways to compare
- A condition that can’t be read skips the run rather than guessing
- New workflows start off; version numbers track your edits
Read what it did. Especially when it didn’t.
Every run keeps a step-by-step record, down to the error message on the step that raised it, because a gap you can see is a gap you can fix.
- One row per run, one per step, timestamps on both
- Each step keeps its output: the record it made, the score it moved
- An error keeps its message on the step that raised it
- Everything after an error is written as skipped, visibly
- A workflow’s own stage change can’t trigger workflows: no loops
Why it works this way. Three fences worth naming.
It fires on the crossing, not the state
The engagement score recomputes nightly. If the threshold trigger fired on state instead of on crossing, every contact above your line would re-fire every night, so it fires once, at the crossing.
The field-setter has a fence
Set a field can only write to fields on a list we control, and consent and identity fields are off that list. An automation cannot quietly opt someone into email or rewrite who they are.
Webhooks are deliveries, not hopes
Calling a webhook queues a signed delivery with retries and a record. Your endpoint being down at 2 a.m. is a visible retry, not a lost event.
Six steps, one honest ledger
The welcome that ran on a first gift: four steps completed with their outputs, the webhook that errored with its message kept, and the step after it skipped in the open.
Waits and branches live in Pulse. Timed, branching sequences belong to journeys, not workflows.
Six things, all real writes: set a field, move a lifecycle stage, create a custom-object record, call a webhook, emit an engagement, create an activity. Each step’s output lands in the run history.
Not yet. A workflow is a straight line run in order. Branches and waits are designed into the data model but have not shipped, and we would rather name that than let you plan a drip around it. Timed, branching sequences live in Pulse journeys today.
Neither yet. The visible workarounds are honest ones: create an activity on the record, or call a webhook and let the receiving end notify whoever needs to know.
If the trigger genuinely happens twice, yes: there is no enrolment model suppressing repeats. The one guard is the threshold trigger, which fires on crossing rather than on sitting above the line.
The step goes to errored with its message, every remaining step is recorded as skipped, and the run is marked errored. The next workflow on the same trigger still runs; one failure never takes the rest down.