Automation is a team sport, so the builder should act like one

There's a myth that automation is a solo activity. One clever person wires up a workflow, and it quietly runs forever. Anyone who has actually lived with production automations knows better. The workflow that pays vendors gets touched by finance, by ops, and by whoever happens to be on call the night it breaks. It outlives the person who first built it. It changes hands, changes requirements, and changes shape. Automation is a team sport, and for a long time the tools didn't act like one.

A lot of our recent work has gone into closing that gap. The thread running through it is a single belief: a workflow is not a personal script, it's shared infrastructure, and it should be built and maintained the way teams build everything else that matters.

Version history, so "who changed this, and why" has an answer

The scariest sentence in automation is "it worked yesterday." When a workflow that touches real money starts behaving differently, the first question is always the same: what changed?

Now you can answer it. Every workflow keeps a version history. You can see how it evolved over time, compare it against a version you know was good, and, the part that actually lets people sleep, roll back to a previous version in one click. A bad edit stops being a crisis and becomes an undo. That safety net quietly changes how a team behaves. People are willing to sharpen a workflow when reverting is instant and free, and they get cautious and slow when it isn't.

Real-time presence, so two people don't edit blind

Google Docs solved a problem word processors didn't know they had: you should never overwrite a colleague because you couldn't see them typing. Workflow builders had the same blind spot, with higher stakes.

Lodol now shows presence in the editor. You can see which teammates are viewing a workflow right now, so the classic disaster, two people editing the same automation, each unaware of the other, one silently clobbering the other's work, just doesn't happen. Coordination stops being a Slack message that opens with "hey are you in the AP workflow right now?"

Comments where the work actually is

Feedback on a workflow used to live somewhere the workflow didn't. A thread, a ticket, a meeting. By the time you were making the change, the context was three tabs away.

So we brought the conversation onto the canvas. You can pin a comment directly to a step, keep the discussion in a sidebar next to the workflow it's about, filter the threads, and drag a pin to reposition it. Because the pins stay anchored to the step they belong to, even when the edit sidebar opens over them, a comment about "this approval threshold" keeps pointing at that approval threshold rather than at empty canvas. The review happens where the work is, which is the only place it has ever really belonged.

Roles and permissions, because not everyone should change everything

Shared infrastructure needs boundaries. On a team of any size, the person who reviews a workflow, the person allowed to publish it, and the person who can run it are often three different people, and the tool should respect that instead of flattening everyone into "can edit."

Custom roles let you group permissions and decide who can edit, approve, and run. Paired with audit logs that record every action, you get the thing careful and regulated teams actually need, which is not just automation but automation with accountability. Who did what, when, and under whose authority becomes a question with a real answer rather than a shrug.

The through-line

Step back and a pattern shows up. Version history is git-like safety. Presence is Docs-like awareness. Pinned comments are review that lives where the work does. Roles are accountability. None of these ideas is new to software teams. What's new is bringing them to automation, which for too long got treated as a place where one person quietly did something clever and hoped nobody would ever have to touch it again.

Someone is going to touch it again. More people, for longer, than whoever built it first. Building it should feel less like editing a fragile personal macro and more like collaborating on something the whole team owns, because that is what it is.

Building automations with more than one person?
See how version history, presence, comments, and roles turn a workflow from a personal script into shared infrastructure your team can trust.