Automating with workflows
A customer signs up, then creates their first project the next day. Sending “create your first project” two days after signup would miss what they have already done. A workflow can check their progress before deciding to send.
In maxclicks, you describe that journey to maxinja or build it on a canvas, review the steps and publish. Each qualifying trigger starts a run: one execution whose decisions and results you can inspect.
Follow one customer
| Stage | What it means for the signup |
|---|---|
| Signup event | Identify the person who just joined. |
| Find Records | Bring that person’s contact into the journey. |
| Delay | Wait two days. |
| Query | Count projects this person created. A teammate’s work does not count. |
| If/Else | End if they have a project; continue if they have none. |
| AI, when needed | Prepare a first-project suggestion from their stated goal. |
| Send Email | Send the suggestion to that contact, subject to sending eligibility. |
Query reads facts. If/Else applies a rule. AI interprets supplied context. You can use them together without asking a model to make every decision. For personalized wording directly inside an email, Adaptyle is another option.
Build this signup workflow when you are ready to try it.
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 Scheduled evaluated 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 qualifying trigger starts a run: one execution of the workflow. An event can identify a customer, a webhook can start with a JSON payload, and a scheduled trigger can start empty. Later steps select the data they need from what earlier steps supplied and can add more.
| After this step | The run's data holds |
|---|---|
| Event Fired | The signup event. |
| Find Records | The event and the identified user. |
| Query | The earlier context and the user’s project count. |
| AI | The earlier context and a first-project suggestion. |
| Send Email | Uses the configured recipient and message data. |
The output of a step gets a name that later steps can reference. For example, Query can pass on projectCheck, and the branch can read its hasProject value. A step cannot use the answer from a step that has not run yet.
Ordinary record values are read as steps need them. Evaluated attributes calculate on demand. Background Scheduled evaluated attributes use generations pinned for the root run and its children, so a run does not silently switch to a newer publication halfway through. 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
Place a lookup after the wait when you need to know what changed during it. In the example, Query counts the user’s own projects after two days; the branch then decides from that answer. Query errors and a valid count of zero are different outcomes.
If/Else can also 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 Evaluated attribute threshold when a Scheduled 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. Use Terminate run to end a selected run, its children and pending continuations. Completed effects remain, and there is no rewind.
- Stop new runs prevents new enrollment while existing runs continue. Resume new runs preserves a separate workflow pause.
- 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
Build the signup follow-up, or use Workflow blocks to choose a step for another journey. Deliverability basics explains domain, consent and sending-health controls before you send.