Our automations builder has been rebuilt from the ground up. Before getting into the why of the work (and some of the design thinking behind it), here's the practical summary of what's changed for you:

• One trigger, many actions. A single automation can now fan out into any number of actions, each with its own timing, filters, and configuration. If you previously had four near-duplicate automations just to cross-post to four networks, those collapse into one.
• A dedicated settings page. Automations have graduated out of their cramped drawer into a full-page builder. Branching workflows, nested filters, and multi-step sequences have room to breathe — and are much easier to read at a glance.
• Redesigned analytics. You can now follow a trigger all the way through each filter, into each action, and down into per-action outcomes like open rates and link clicks. The same pattern powers the stats on individual emails, too.
• Previews against past events. Before you turn an automation on, you can see how it would have fired against the events already in your account — which subscribers it would have tagged, which emails it would have sent, how often the trigger actually hits. No more flipping the switch and hoping.
• Templates to start from. We've added welcome series and cross-posting templates to the docs so you don't need to build from a blank slate.

Want to skip ahead and click around? Here's the new builder, live:

If you were already getting by with the old one-to-one automations, nothing breaks — your existing automations keep working. The new shape just gives you a lot more room to grow into. With that out of the way, here's the longer story of how we got here.

One-to-one-to-one-to-many

During his time at Xerox PARC, Alan Kay coined the phrase "make simple things simple and complex things possible." He was building Smalltalk, a language that broke programs into structures that communicated like living organisms — intuitive enough for children, powerful enough to handle "50,000 kinds of things we hadn't thought of done by 50,000 programmers we hadn't met."

That phrase echoes in my head whenever I see the word "Automation" in software. Most tools pick a side: easy to set up but shallow, or deep and powerful but effectively an API. Buttondown had both — a simple automation builder for one-shot triggers, and a rich API surface for scripting complex workflows — but there was a huge gulf between the two, and our web app offered no bridges.

In the months since Justin asked me to wrestle with this problem, I've been shifting the pieces of our automations builder to click together more like Lego blocks than jigsaw pieces. Here's what we built and why.

One of the key constraints of Buttondown's previous automation builder was the shape of each automation: one event could cause one and only one action. To accomplish something like cross-posting an email to five social media networks, you'd need to create five separate automations. Not only does this take time and effort, but it's a pain to update later if you want to experiment with timing, wording, or tagging.

In hindsight, it's obvious that automations need to be one-to-many, not one-to-one. An event should be able to set off any number of actions, each with their own timing and unique configuration. For example: you should be able to cross-post to five networks from a single trigger, or send a welcome series that branches based on how a subscriber signed up. The shape of the automation should match the shape of the workflow; most workflows aren't straight lines.

Unfortunately, we had baked the one-to-one model deeply into our automations, from the data model, to the UI layout, to the way we tracked performance. Pulling the one-to-many thread unraveled those fundamental assumptions, cascading the work out across the codebase and interface. Filters that made sense gating a single action now needed to work across many. Timing that used to be set at the automation level had to drop down to every action. Our analytics components, which used to show a flow from trigger to action, needed to account for branching paths and parallel execution. It was like peeling an onion, but the onion was on fire.

A dedicated control surface

Given new superpowers and all the complexity that comes with them, one-to-many automations need a dedicated control surface. The previous interface was a stodgy drawer, which overflowed the instant we tested adding a second action to a simple automation. You can't stuff a branching, multi-action workflow into a settings drawer and expect anyone to build confidently inside it. So we built out an automations settings page to give you room to build and experiment.

By separating the building and testing of an automation from the understanding and auditing of one, we were able to push both interfaces even further than before. Now you can visualize all the actions an automation can take, and tune each in detail with custom timing and configurations.

This also gave us an opportunity to sand down the rough edges that are inevitable when you squeeze a complex feature into a small drawer. The flow of an event through filters to actions reads like a story. Buttons and selects nest neatly. Even when automations get complex, they're still easy to grok at a glance.

Drilling into the data

Before, tracking a simple automation's performance was a matter of checking how often it ran. In the old one-to-one world, it was easy to draw a line between triggers and actions. But with multiple cascading actions and stepped filters, the old audience and analytics tables got ugly fast.

Breaking the automation's configuration out into a dedicated view let us make the analytics panel even more powerful and intuitive. Now you can track the path of a trigger through each filter, through to each action, down into outcomes like email open rates and link clicks. This is one of my favorite things about software design: solving the hard case — nested, composable analytics — gave us a pattern that also simplified the easy ones, like stats on an individual email's page.

And like any good design process, building this analytics pattern showed us even more possibilities ahead. Justin put it succinctly: "maybe we should create the world's first vertical sankey diagram."

Time travel

One of the things that makes it hard to turn on an automation is just how wrong it can go. Not to scare you, but if you've spent enough time around automation, you've probably deleted a database or two.

In making complex automations more possible, we realized we'd need to give users a way to test them before turning them on. But how do you test something that hasn't happened yet? Simulating future events sounded fun but fragile. When it comes to automations (and, well, everything) the past has a lot more to say than the future.

So we designed automations previews to let you see how your automation would have performed if it had been running all along. By checking your automation against events that have already happened — subscribers you've gained, emails you've sent, tags you've added — we can give you a complete picture of how the automation works. Would the filters pass the right events? How often does the trigger actually fire? These questions are easy to answer when looking at your automation through the lens of the new preview feature.

Can we make complex things simple, too?

We've updated our documentation and landing pages with templates for welcome series and cross-posting automations to get you started. These updates lay the groundwork for you to build automations from the simplest to the most complex, all without needing to script against the API. Want to connect your Buttondown to your AI agent and power an email support system with rich data? Go for it. What about building an entire newsletter network with multiple membership entry points and subscriber-exclusive messaging, all with granular data reporting? You got it. A Turing machine that can compute any program using only email automations? I won't say I haven't considered it.

We want Buttondown to make the simple things simple and the complex things possible. And like Alan Kay's vision for Smalltalk, we want the complex things to be within reach of every user, regardless of technical background. Our work in rebuilding automations — moving from a strict one-to-one model into a one-to-many world of possibilities, and tackling the UI design that follows — takes us a few more steps in that direction. Happy building!