Author: onetwothreeadmin

ConvertKit’s visual automation builder replaced the old “sequence + rule” system in 2019, and most solo operators treat it like a flowchart app: drag some boxes, draw some lines, hit publish. It works—until you nest a few conditional branches or try to merge two paths back into one step, and subscribers start falling through cracks you didn’t know existed.

The builder feels intuitive because it mirrors how we sketch funnels on paper. But the canvas hides execution logic that doesn’t always match what the diagram suggests. Here’s what actually happens under the hood, when to use it, and one non-obvious trick that keeps automations from breaking when you scale them.

How the builder actually executes branches

ConvertKit’s automation engine evaluates conditions at the moment a subscriber reaches that step. If you branch on “has tag X,” the system checks tag state right then—not when they entered the automation, and not continuously. That’s fine for simple yes/no splits, but it creates two common failure modes.

First: timing gaps in nested branches. If you add a five-day delay before a conditional check, and the subscriber gains or loses the relevant tag during that delay, the branch decision reflects the tag state on day five—not day zero. Most operators assume the branch locks in at entry. It doesn’t.

Second: parallel branches don’t merge cleanly. The canvas lets you draw two separate paths that converge into a single “Send email” step. Visually, it looks like both paths feed into one action. In practice, ConvertKit treats each incoming connection as a separate trigger. If a subscriber qualifies for both branches simultaneously—say, they have two tags that each route them down a different path—they’ll hit that shared email step twice and receive duplicate sends. There’s no automatic deduplication at merge points.

When to use the visual builder vs. segments and broadcasts

The automation builder shines when you need time-based sequencing with simple branching—onboarding flows, drip courses, or post-purchase follow-ups where the next step depends on one or two clear conditions (opened email, clicked link, purchased product). It’s purpose-built for “if this, then wait X days, then do that” logic.

It’s the wrong tool when you need complex multi-condition logic or frequent re-evaluation. If your segmentation involves “has tag A and tag B, but not tag C, and joined before date D,” you’re better off using ConvertKit’s segment builder and sending one-off broadcasts to that segment. Segments re-evaluate in real time; automations evaluate once per step. Trying to replicate segment logic inside an automation canvas leads to branching spaghetti that’s impossible to debug when a subscriber reports they didn’t get an email.

The other time to avoid the builder: when you need to pause or edit a live flow without stopping new subscribers. ConvertKit doesn’t let you edit an active automation. You have to duplicate it, make changes, archive the old one, and redirect new subscribers to the new version. Anyone mid-flight in the old automation stays there until they complete it or you manually move them. For high-traffic funnels, that’s a versioning nightmare. A combination of tags, segments, and scheduled broadcasts gives you more control.

The non-obvious trick: use events, not tags, for branch conditions

Most operators branch on tags because tags are visible and easy to apply. But tags are state—they can be added, removed, or changed by other automations, manual bulk actions, or integrations. If two automations both manipulate the same tag, you’ve introduced race conditions you can’t see on the canvas.

ConvertKit’s event triggers—”Purchased product,” “Completed form,” “Clicked link in email”—are immutable. Once an event fires, it stays in the subscriber’s history. Branching on events instead of tags eliminates the timing-gap problem: you’re checking “did this happen” rather than “does this tag currently exist.”

Practical example: instead of branching on “has tag: clicked-link-in-welcome-email” (which you’d apply via a separate link-trigger automation), branch directly on the event “Clicked link in [specific email].” It’s one fewer moving part, and the condition can’t be accidentally overwritten by a bulk tag removal you run three months later.

The trade-off: events are harder to manipulate manually. If you need to retroactively mark someone as having completed a step, you can add a tag by hand; you can’t fake an event. For most use cases, that’s a feature, not a bug—it forces you to model your automation around actual subscriber behavior rather than abstract state.

What to check before you publish

Before you activate any automation with more than two branch points, walk through it as if you’re a subscriber who qualifies for multiple paths simultaneously. ConvertKit’s preview mode only shows you one path at a time; it won’t surface the duplicate-send issue. Manually trace each route on paper or in a separate doc.

Also check your delays. ConvertKit’s builder lets you stack delays inside branches, and the total wait time isn’t surfaced anywhere in the UI. I’ve seen onboarding automations where the “fast track” branch accidentally included 14 days of cumulative delays because each step added “wait 2 days” without the operator realizing they’d nested four of them. Subscribers stopped engaging because the follow-up came two weeks late.

Finally, set up a test subscriber with a disposable email and run them through the full flow in real time—don’t just use preview mode. Create the edge-case conditions: apply conflicting tags, click links out of order, purchase mid-sequence. You’ll catch merge issues and timing gaps that don’t show up in the visual review.

If you’re running ConvertKit automations and want more tools and breakdowns like this one, subscribe to One Two Three Send. We cover the features and gotchas that don’t make it into official docs—one concrete piece per week, no fluff.