If This, Then That, Unless…
Single-step automations break on the first exception. Flows with branches and waits let one automation handle the real case — and a test run shows what it would do before it sends anything.
Most automations start simple. A deal moves to "Proposal sent", so a follow-up task is created three days out. It works for a month. Then a large deal goes to proposal and the three-day nudge is far too early. A small one is already signed by the time the task appears. Someone adds a second automation to handle the exception, then a third, and eventually nobody is sure which rule fired or why.
The problem is not automation. It is automation that can only say one thing.
One flow, not five rules
In Swelis One, opening an automation shows its flow: the trigger on top and the steps below it, on a canvas you can drag and zoom. Hover a line and press + to add a step anywhere. That alone changes how people think about it — the automation is a picture of the process rather than a list of disconnected rules.
Two steps do most of the work. If / else splits the flow on any value or custom field into a Yes and a No path. Wait pauses for minutes, hours or days, or until a weekday and time. And after a wait, the flow sees the record as it is then — not as it was when the flow started.
The steps that matter
Branches are only useful if the paths can do real work. Alongside emails and tasks, a flow can update a field, assign an owner, add or remove a tag, move a deal to another stage, create a deal and post to Slack. Triggers include stage changes, stale deals, new leads, field changes and upcoming dates such as a contract end or a birthday.
Put together, the proposal case looks like this: trigger on the stage move, branch on deal value, wait a different length on each side, check whether the deal has moved, and only then create the follow-up — assigned to the owner on small deals and to a second reviewer on large ones. A flow can also create a deal in another pipeline — a won sale opening its renewal.
An automation you cannot test is an automation nobody trusts. And an automation nobody trusts gets switched off.
Test before it touches anyone
Test walks the flow with a real record or sample values and shows on each step what would happen — without sending or saving anything. It is the difference between hoping a branch is right and seeing it take the right path for the record in front of you.
Once it is live, Runs draws the path each past run took, with the error on the step that failed. When someone asks why a client got a particular email, the answer is a picture, not an investigation.
Keep it readable
Flows make it easy to build big things. A few habits keep them maintainable:
- One trigger, one job. If a flow does two unrelated things, it should be two flows.
- Branch on fields, not on text. A dropdown value is a reliable condition; a phrase in a note is not.
- Use folders. Group flows by stage or by team, and duplicate a working flow instead of starting from scratch.
- Watch the run bars. The list shows fourteen days of runs plus waiting and failed counts — a flow that suddenly stops running is telling you something.
The best automation is the one that handles the exception without a second rule. Now it can. The same canvas also runs chat automations in the Social module.
Want to see a follow-up run? The Automations scene on our features page lets you pick a delay and fast-forward the week.