Automating with workflows
A workflow turns your lifecycle strategy into a sequence with a visible trigger, timing and decision points. Ask maxinja to build the journey or configure it on the canvas, then inspect and publish it. Each qualifying trigger starts an individual run.
Triggers, steps, and links
Every workflow is three things.
- Triggers start a run. They have no incoming links. A trigger is a scheduled time, a record created or updated, a record deleted, an event fired, an email event (open, click, bounce), a stored computed attribute crossing a threshold, or an incoming webhook. Every workflow needs at least one.
- Steps do the work after the trigger.
- Links connect steps. They set the order, and where a step branches, which way a run goes. Each step has ordered output points called slots, and each slot has at most one outgoing link.
Loops are not allowed: a link cannot send a run back to an earlier step. The reference groups the 21 step types into five families (triggers, enhancers, controllers, actions, decorators), where controllers cover both branching and delays. See Workflow blocks for the full catalog.
A run carries data
Each time a trigger fires, maxclicks starts a run: one journey through the workflow for one record. As the run moves from step to step, it carries data that grows. The trigger adds the first property. Each later step reads everything already there and can add more.
| After this step | The run's data holds |
|---|---|
Event Fired (trigger) | { event } |
Find Records (attach the buyer) | { event, contact } |
Set Value (compute a tier) | { event, contact, tier } |
Send Email (personalize with all of it) | consumes the whole set |
This is why a later step can use something an earlier one produced: the value is already traveling with the run. Ordinary record values are read as steps need them. Stored computed attributes use generations pinned for the root run and its children, so they do not silently change to a newer calculation halfway through the journey. Trigger and decision evidence can also be saved as a snapshot. See attribute expansion.
Runs can be executing, waiting on a saved delay, parked by a workflow pause, or waiting for credits and capacity. A terminal failure ends a run, while temporary waits and safe infrastructure retries can continue. Inspect the recorded reason before re-triggering.
You describe step logic to maxinja
Most steps have one field where you describe what you want in plain language, and maxinja builds the logic. It is the same pattern you met in segments: you type the outcome, maxinja builds it and shows a readable description rather than code, and you refine it with a follow-up.
What maxinja produces fits the step:
| Step | You describe | maxinja builds |
|---|---|---|
If/Else, Switch, a filtered trigger | a yes/no question | a check that routes the run |
Find Records, Delete Records | who to act on | a database query |
Set Value, Query | a value to compute | the value and its shape |
Delay | how long to wait | a duration or a target time |
The available-data panel in the editor shows every value the run is carrying at that step, so you know what you can reference.
Ask the right question after a wait
A two-day wait alone does not make an onboarding email relevant. Follow it with a decision about this customer's activity. If/Else can evaluate supplied data, or use Customer event history to check whether a chosen event has or has not occurred within a saved lookback window. Allow time for late events and choose whether the match is about the customer or one correlated transaction.
Use Trait Threshold when a computed value crosses a boundary. Publishing sets its baseline; already-matching customers do not all start a run. Use a separately reviewed audience if you need that initial campaign.
Publishing, versions, and runs
You build a workflow freely on the canvas, and steps can stay half-finished while you work. Publishing checks the whole graph (at least one trigger, no loops, no unfinished steps) and freezes it as a version that cannot change afterwards.
- After any edit, the workflow is marked dirty until you publish again.
- Only the latest published version starts new runs. Runs already in flight finish on the version they began on.
- Pause prevents new runs and parks existing execution before more steps run. Saved delays keep their deadline. There is no individual run cancellation or rewind, and already completed effects remain.
- Every step is checked again right before it runs, so a broken step is caught then and there.
Every run records a full step history. Open the run history to see which path a run took, the email it sent, and where anything failed. It is your first stop when an automation misbehaves.
Next
Read Workflows for the complete reference, then Deliverability basics for domain, consent and sending-health controls.