Create a workflow
Turn the journey brief into a workflow your team can review. Ask maxinja to build it or add and configure steps on the canvas, then check the trigger, conditions, timing and email before publishing. The workflow overview explains how those parts work together.
Start a workflow
Open the editor
Open Workflows in the navigation bar at the top, then New workflow. An empty canvas opens.
Or copy an existing one
Open the ⋯ menu next to a workflow and choose Duplicate. The copy is an unpublished draft.
Canvas controls: scroll or drag empty space to pan, use the bottom-left controls to zoom, and hold Command while dragging a step to snap it to the grid.
Add steps
A workflow must start with a trigger step. Add one first, then add the steps that run after it.
- Add: hover a step and click the + that appears. Pick a type from the list. The new step is linked to the one you added it from.
- Delete: select a step and press Backspace. Hold Shift to select several, then delete them together.
Each run carries its own data. The trigger puts the first value there, and every step after it can read what earlier steps added. See the step list for what each type needs and what it adds.
Connect slots to steps
Steps connect through slots and links.
- A slot is an output point on a step. A Switch or If/Else step has one slot per branch.
- A link connects one slot to one target step. A slot has at most one outgoing link.
- Connect: drag from a slot's connection point to the target step.
- Disconnect: select the link and press Backspace.
Configure a step
Select a step to open its panel. You never hand-write conditions, values, queries, or audiences: you describe what you want in plain language, maxinja builds the logic, and it shows you a readable summary to confirm or refine. See step logic.
Build progressively
Steps can sit half-configured while you work. The editor displays issues as you configure them, and publication performs the final graph validation. Lay out the flow, then resolve the data and behavior on each step. To leave an explanation for your team, add a Note step: it sits on the canvas and takes no part in a run.
Review the journey as an operator
Trace one realistic customer through the canvas. Confirm the trigger represents the intended milestone, the records belong to that customer, each branch has the data it needs and every Send Email has one eligible recipient. Preview the step-owned email using Data, Personalize and Checks in the composer rail.
Check every fan-out control and list size. If a step finds all contacts and processes each separately, later steps run once per result. Decide how an empty result should behave. For HTTP Request, agree an idempotent receiving contract and a valid response shape before letting the journey act on another system.
For absence-of-event logic, use the explicit event-history window and lateness controls. For Trait Threshold, remember publication establishes a baseline instead of immediately triggering existing matches. The block library explains these differences.
Validate at publish
Publishing checks the whole workflow and stops on any error. Clear each message to publish. Errors about the workflow as a whole:
| What is wrong | Message |
|---|---|
| No trigger step | A workflow must have at least one trigger step. |
| A trigger has an incoming link | Trigger steps must not have incoming links. |
| A step that is not a trigger or a Note has no incoming link | This step must have at least one incoming link. |
| A step loops back to an earlier one | Currently, cycles are not supported. |
Individual steps flag their own gaps too, for example Schema is not specified. or The condition requirements need to be converted to a predicate. Rewiring the canvas so a step no longer receives a value it was set up to use also flags that step.
Publish
Click Publish at the top. The button appears only while the workflow has unpublished changes. Publishing takes a frozen copy of the workflow, called a version, and makes it the live one. It also resumes a paused workflow.
- New triggers start runs on the latest published version.
- Runs already underway finish on the version they started on.
- Editing after publishing saves a draft. The changes take effect at the next publish.
Use Live / Paused to prevent new runs and park existing execution. It does not reverse completed effects, and publishing unpauses the workflow. Inspect old runs before publishing a fix because they retain their original version.
Related
- Workflows: steps, slots and links, versioning, and the trigger API.
- Workflow blocks: every step type, explained.
- Manage workflows: publishing, pausing, and versions.
- Workflow runs: what happened on each run.