Umbraco Automate: Developer Automation or Marketing Automation?

I've been working with Kentico for many years, where marketing automation has been part of the platform for over a decade. So when Umbraco Automate was announced, I assumed I already knew what it was going to be: campaigns, customer journeys, lead nurturing, with a different logo on it.

Then I joined the Umbraco Kent Meetup virtually to watch Owain Williams present "Automation for the people", and it was clear I'd guessed wrong. The demo took a familiar problem, publishing a blog post and then manually sharing it across LinkedIn, Bluesky and Mastodon, and solved it with something that looked much more like integration plumbing than marketing.

That leads to the question this post is really about: what role is Umbraco Automate actually trying to fill within the Umbraco ecosystem?

Owain first came across Automate at MVP Summit and Codegarden, and the session paired the fundamentals with a real implementation running on his own site. Using Umbraco 17, he covered installing and configuring the package, creating a workspace, managing connections and permissions, and the core concepts behind a flow: triggers, actions and bindings.

One practical detail that caught my attention was the recommendation to use a dedicated database for Automate. As that's not currently possible on Umbraco Cloud, Owain showed how a named connection string can be used to point Automate at the existing Umbraco database instead.

He also demonstrated how Automate can be extended through custom development, showing both a custom Trigger and a custom Action. Seeing how these components are surfaced directly within the workflow designer highlighted how extensible the platform is beyond the built-in functionality.

The session concluded with a complete workflow that reacted to content being published and automatically posted to LinkedIn, Bluesky and Mastodon via a set of social integrations built from Owain's open-source packages. The workflow even included a step to rewrite hashtags so that posts could be tailored for different platforms before being published.

One of the most interesting parts of the evening came after the demo itself, when people started discussing where Umbraco Automate fits within the wider Umbraco ecosystem.

Several comparisons were made with Umbraco Workflow, with the general feeling being that Workflow is aimed primarily at content teams and approval processes, whereas Automate feels more like a visual, low-code layer over the sort of integrations developers have traditionally built using notification handlers and custom code.

My own view is that Automate currently feels much closer to developer tooling than marketer tooling. Automate is removing a lot of boilerplate code, but it still expects users to understand the concepts of triggers, actions, bindings, and data mapping. Bindings in particular, which use ${...} expressions to reference values from previous steps, feel far more familiar to a developer than a marketer or content editor.

With this in mind, I think the early adopters will be developers. Over time, content editors and marketers may benefit from the workflows being built, but I'm less convinced they'll be the people creating and maintaining them.

Automate is intentionally very open and extensible. Owain's social media integrations were built using his own open-source packages, and it's easy to imagine the wider community building additional triggers, actions and connectors as adoption grows.

Automation platforms aren't new. In Kentico, marketing automation has been part of the platform since Kentico 7 back in 2012: users could build workflows, react to events and trigger actions, with the same extensibility options through custom Triggers and custom Actions.

The interesting thing is that although they both use the word "automation", they're aimed at very different audiences.

Kentico is marketer focused, geared towards customer journeys, forms, lead nurturing and segmentation. Whereas Umbraco Automate is developer oriented, helping with integrations, system events, and orchestration.

The clearest difference is in how each one asks you to express logic. Kentico gives you a rule builder, where you assemble conditions from fields, operators and values in the UI, and that has been refined further since marketing automation was reintroduced in Xperience by Kentico. A marketer can build a flow exactly where they need it without learning a syntax. Automate does offer a binding picker, so you aren't typing everything from memory, but what it inserts is still an expression: camelCase property paths, step aliases and pipe filters, so ContentName on the trigger becomes ${trigger.contentName}. Same underlying idea, very different expectation of the person building it.

This isn't a criticism of either platform. They're solving different problems, while using some of the same underlying concepts and techniques.

Before attending the session, I assumed Umbraco Automate was going to be another marketing automation tool. After seeing Owain's demo and listening to the discussion afterwards, I think it's better described as a workflow and integration platform for Umbraco.

While it's presented as drag-and-drop automation for marketing teams, it currently feels more developer-focused than marketer-focused. Many of the scenarios demonstrated, from social media publishing to external integrations, are things developers have traditionally solved with custom code, and Automate provides a much more accessible way to build and maintain those processes.

The sense I've picked up from the community so far is that nobody is really asking Automate to be a marketing tool, and if developers are the intended audience then it doesn't need to be one. But if it ever does want to reach editors and marketers, the syntax is the thing standing in the way. Something closer to Kentico's rule builder, where the result reads as a rule rather than an expression, is what would make it genuinely low-code, and that would make an already useful package a far more powerful one.

Thanks again to Owain Williams for the session. It was useful to see Automate being used to solve a real problem rather than just exploring features in isolation.