Umbraco Automate: what it is, and the features that have shaped it since launch

Umbraco Automate is an automation engine built into the Umbraco backoffice. You build workflows on a visual canvas by connecting a trigger, the event that starts the flow, to a chain of actions that do the work. It works like the "if this, then that" tools you may already know, except that it runs inside your own Umbraco site rather than on an external automation platform. Your data only leaves your environment when one of your steps sends it somewhere.

It's open source, and Umbraco puts no limits on the number of runs, automations, triggers, actions or users. It runs on Umbraco 17 and 18, with a separate release line for each.

A handful of concepts cover almost everything:

• A workspace groups automations, and controls which users and which connections can be used inside it. Each workspace runs its automations as a service account.
• An automation has exactly one trigger, followed by a sequence of steps.
• A trigger is the event that starts a run. The built-in ones cover content, media, members and backoffice users, plus a Manual Trigger, a Scheduled Trigger driven by a CRON expression, and a Webhook trigger with HMAC or shared-secret authentication. Content and media triggers also come in batch versions, which start one run for a whole save or publish operation.
• An action is a unit of work, such as an HTTP request, sending an email, or publishing content.
• A connection stores the credentials for an external service, such as Slack, so several actions can share them.
• Bindings pass data between steps with a ${ ... } syntax. A step can read the trigger's output, or the output of any earlier step.
• Control flow nodes (If, Switch, While, For Each and Parallel) let a flow branch and loop.
• Approval steps pause a run until a person approves or rejects it.
• Every run is recorded with each step's inputs, outputs, errors and timing, and automations have draft and published versions with rollback.

Umbraco also ships add-on packages that bring their own triggers and actions: Slack, AI (through Umbraco.AI agents), Forms, Commerce, Engage, Deploy, Workflow and UI Builder. The Deploy add-on moves automations, workspaces and connections between environments. If none of that covers what you need, you can write your own triggers, actions, connection types and notification channels in C#.

Umbraco released the first beta of Automate for Umbraco 17 on 9 June 2026 and presented the product at Codegarden 2026. A beta for Umbraco 18 followed on 24 June, and Umbraco launched Automate publicly on 9 July. Since then a new minor version has shipped every two to four weeks, released for Umbraco 17 and 18 on the same day with the same features. At the time of writing the latest is 17.5.0 and 18.5.0, from 1 October.

That first beta already had workspaces, connections, the canvas with control flow, approvals and run history. The features below all arrived after it.

Approval steps were there from the start, but a rejection could stop the run and report it as Failed. Since 17.2.0 and 18.2.0, the Request Approval node has separate Approved and Rejected handles on the canvas, so you can build what happens next in either case: publish on approval, notify the author on rejection. A rejected run now reports Rejected, and the step's outcome output reads Approved or Rejected.

In the x.5.0 releases, a run waiting for a decision also shows as Suspended and sends Suspended notifications, so you can tell which runs are waiting for someone to decide.

The For Each, While and Parallel nodes gained Body and Done handles in 17.3.0 and 18.3.0. You connect the steps that repeat (or run side by side) to Body, and what happens afterwards to Done. A Parallel node can also fan out into more than one branch.

Since 17.4.0 and 18.4.0, every step has its own name, alias, error behaviour and retry controls. A flaky HTTP call can retry a few times before giving up, and a step that's allowed to fail doesn't have to take the whole run down with it.

The Run Script action, also new in 17.4.0 and 18.4.0, runs a short JavaScript snippet in a sandbox. It covers the jobs that fall between the built-in actions and writing a custom action in C#, like reshaping a payload or combining the output of earlier steps. On Umbraco 18 it has an output schema setting, so later steps can bind to the script's result. Since the x.5.0 releases the script receives the binding context as data, and fetch is turned off by default for new steps.

At launch, Run now (starting an automation by hand) belonged to the Manual Trigger. Scheduled triggers gained it in 17.1.0 and 18.1.0, and in 17.4.0 and 18.4.0 it became something any trigger can opt in to, custom triggers included. The Webhook trigger supports it by replaying a saved test request, which makes webhook automations much easier to build and test without an external system calling them.

The Start Automation action, added in the x.5.0 releases, starts another automation from a step, so common work can live in one automation that the others call. It blocks cycles and respects a maximum chain depth, so one automation can't set off an endless loop of others.

The x.5.0 releases also added Create Content, Create Media, Move Content and Move Media. Automations could already read and publish content, and 17.4.0 and 18.4.0 brought actions for finding and reading media. Now they can create items under a parent, with property values filled from bindings, and move items to a new parent or to the root. Content created this way respects the chosen culture for variant properties.

Run history was always recorded, but in the x.5.0 releases it became far more useful for debugging. The run view now shows the data that went into and came out of every step, including the trigger's own data. Actions can also write log entries to the run, with sensitive values redacted, and the built-in actions already do.

Umbraco's own launch examples are a good place to start: onboarding new customers, translating updated content across international sites, and taking routine admin work off people's plates. With the AI add-on, an automation can call an Umbraco.AI agent as a step to generate alt text for an image, transcribe media or write a summary. Put an approval step after the agent and a person reviews the result before it goes anywhere. At launch, Umbraco also pointed to community extensions that post to LinkedIn and send push notifications.

The built-in triggers suggest plenty more. A Content Published trigger can tell a Slack channel or a translator that a page has changed. A Scheduled trigger can run a nightly check or clean-up, and a Webhook trigger lets an external system, such as a CRM or a payment provider, start an automation in Umbraco. Member Saved can kick off a welcome flow, and the User Login Failed and User Locked triggers can alert an administrator.

On my own site I've leaned on custom actions. The ones I've written turn a block of markdown into a draft blog post, calculate reading time, pull images from Unsplash and book details from Open Library, post messages to Discord and Microsoft Teams, and detect the weather and the season for the site's theme. Paired with my Manual Trigger (with Input) package, the markdown action means an editor can paste a post into Run with input… and get a draft back.

Alongside the new features, several releases tightened security and made runs more dependable:

• The webhook endpoint authenticates the caller before revealing anything about the automation, and no longer stores the caller's secret or signature with the run.
• Outbound requests to private and reserved network addresses are refused.
• A workspace's service account must now be an API user.
• Approvals check that the person deciding has access to the workspace.
• HTTP responses are capped at 10 MB by default (configurable with Execution:MaxHttpResponseBodyBytes).
• A run interrupted by a server restart is marked as failed when the node comes back, rather than resuming part of the way through.

A couple of these affected me directly. When I set up a fresh test site recently, the workspace wouldn't accept a normal admin user as its service account, which is the API-user rule. And because Run now became something a trigger opts in to, the custom trigger in my Manual Trigger (with Input) package doesn't offer Run now at all. That's what I want, since running it without any input wouldn't make sense.

Most of these changes are additions, but a few alter existing behaviour:

1. HTTP responses larger than 10 MB fail from 17.0.0 and 18.0.0 onwards, unless you raise Execution:MaxHttpResponseBodyBytes.
2. In 17.2.0 and 18.2.0, a rejected approval no longer fails the run, and its outcome changed from 0/1 to Approved/Rejected. Conditions written against the number need updating.
3. In 17.5.0 and 18.5.0, service accounts must be API users, Execution:MaxConcurrentRuns actually takes effect (check for a copied example value of 10), webhook error codes changed, and the Umbraco:Automate:Enabled and Governance settings became obsolete ahead of their removal in Automate 19.

The release notes cover the details for each version.

• Umbraco Automate release notes (v18)
• Umbraco Automate release notes (v17)
• Umbraco Automate documentation
• Launching Umbraco Automate (Umbraco blog)
• Product update: Codegarden keynote highlights, Q2 2026 (Umbraco blog)
• Umbraco.Automate on NuGet