How Umbraco Automate Works

A Developer's Guide to Triggers, Actions and C# Extensibility

Umbraco Automate was announced at Codegarden in June 2026 and released on 9 July 2026. It is an open-source, event-driven automation engine that runs inside the Umbraco backoffice, and it is distributed as the "Umbraco.Automate" NuGet package.

For developers, the interesting question is not what the marketing page says. It is what actually happens when a trigger fires, where the code runs, what you can extend, and what you will need to think about when this hits production traffic. This guide covers that.

The one architectural fact that matters

"Automate runs where Umbraco runs."

It is a NuGet package installed into your existing web application, not a separate service and not a third-party cloud platform. There is no external runtime to deploy and no outbound hop to an orchestrator for the workflow logic itself. When a content item is published, the trigger fires in the same process that published it.

That single design decision drives most of what follows: the performance characteristics, the security model, the extensibility story, and the operational considerations at the end of this article.

Underneath, Automate is built on WorkflowCore. This is worth knowing because it explains what you get: a real workflow engine with branching, looping, approval steps that pause a run, and a complete per-step record of every execution. It is not a convenience wrapper around Umbraco's content notification events.

Requirements

`Umbraco.Automate` via NuGet

Installation and configuration

Installation is a standard NuGet operation:

dotnet add package Umbraco.Automate

Automate uses its own database connection string, configured in appsettings.json. For local development and smaller sites, you can point it at the existing Umbraco database with a named connection string:

json:
{
  "Umbraco": {
    "Automate": {
      "UseNamedConnectionString": "umbracoDbDSN"
    }
  }
}

For production estates, a separate database is generally the better choice. Automate records data for every step of every run, so on a site with meaningful automation activity that volume grows steadily. Keeping it separate means a heavy query against run history never competes with the request pipeline serving your visitors, and you can manage its growth independently of your content database.

One setup detail that catches teams out during a first demo: workspace creation and connection management are administrator-only, and creating a workspace requires a service account plus at least one assigned user group. Build that into your environment setup rather than discovering it live.

The concept model

Automate has a deliberately small vocabulary. Seven concepts, and once you know them you can read any automation somebody else built which matters more than it sounds, because most automation tooling fails inside organisations not because it is hard to build in, but because it is hard to inherit.

Triggers

The trigger picker groups available triggers by category Core, Content, Media, Members and Users with add-on packages contributing their own. If you have Umbraco Forms installed, form submission becomes a first-class trigger rather than something you reconstruct from a notification handler. Umbraco Commerce contributes order created, order finalised, order status changed and stock changed. Umbraco Engage contributes persona scored and A/B test started. The AI add-on contributes triggers on agent run lifecycle events.

Webhook triggers let external systems start an automation, which is the inbound half of the integration story.

Actions

Built-in actions cover HTTP requests, sending email, publishing content, writing to the application log, and requesting approval. Add-on packages extend the catalogue Slack, AI, Forms, Commerce, Engage, Deploy, Workflow and UI Builder each contribute their own.

The HTTP request action is the workhorse for integration. Combined with stored connections it reaches any system with an API, and the OpenIddict add-on handles OAuth with over a hundred pre-configured providers, which removes a considerable amount of tedious authentication plumbing.

Bindings

Bindings are how data moves through a run, and they are simpler than they sound. Configure an action, click the binding picker on any supported field, and you insert a placeholder that resolves at runtime:

Content "${ trigger.contentName }" was published

There is no scripting language. That is deliberate, it means a content editor can trace the data path by reading the canvas, without needing you to explain it.

Control flow

`If`, `Switch`, `While` and `ForEach` exist as canvas nodes. Branching business logic take a different path above a value threshold, loop through every item in a basket can be expressed visually rather than escaping into custom code. This matters architecturally, because every piece of logic that stays on the canvas is a piece of logic the business can change without a deployment.

Versioning

Automations follow the same draft and published lifecycle as Umbraco content, with full version history and rollback. One consequence deserves emphasis:

"Draft automations do not run."

An editor can build and save a half-finished workflow on a Friday afternoon and it will sit there inert until somebody deliberately publishes it. That single behaviour removes an entire category of operational accident, and it makes staging genuinely safe.

Tracing a run end to end

Concretely, here is what happens when a visitor submits a quote request form on a site with Umbraco Forms installed.

Umbraco Forms raises its form-submitted event. The Automate trigger bound to that event fires, and the engine creates a run record. A send-email action confirms receipt, with the recipient address supplied by a binding reading the submission. A Slack action notifies the regional team. An If node evaluates the enquiry value and branches to enterprise sales above a threshold. An HTTP action creates the CRM record, authenticating through a stored connection. The run completes, and every step is recorded with its inputs, outputs, errors and timing.

That last part is easy to skim past and hard to overstate. When somebody reports that the confirmation email did not arrive, there is now exactly one place to look rather than a correlation exercise across the CMS, a middleware service and a third-party automation dashboard.

Extending Automate in C#

This is where Automate stops being a low-code tool and becomes something you can build an architecture on.

Three extension points exist:

• Custom trigger react to a domain event the built-in triggers do not cover

• Custom action add a new unit of work

• Custom connection type add a credential type for a service with unusual authentication

Each is a C# class carrying the relevant attribute [Trigger], [Action] or [ConnectionType] inheriting from the corresponding base class. Discovery happens automatically at startup through Umbraco's type loader, so there is no manual registration in a composer.

Two properties of this model matter in practice. First, your action is resolved from the DI container, so it can take repositories, HTTP clients, loggers and any other registered service. It is a first-class part of your application, not a sandboxed script. Second, action settings are strongly typed, and those setting fields support bindings on the canvas, so your C# receives typed values while the editor still gets the binding picker.

You can keep custom actions inside a solution or ship them as your own NuGet package for reuse across projects. For an agency or an internal platform team, that second option is the more interesting one: a library of organization-specific capabilities that every new project inherits.

"Consult the official extending documentation for the exact base class signatures and method shapes before you build. The API surface is young and worth reading first-hand."

This produces a division of labour worth designing for deliberately:
Engineering owns the capabilities. The business owns the compositions.

Your team writes a SyncLeadToCrm action once, properly, with error handling and typed settings. Marketing then composes it into six customer journeys over the following year without raising a ticket. When journey seven needs a capability that does not exist, that is a genuine engineering request rather than a request to rewire an existing flow.

What Automate can and cannot observe

Automate reacts to events. It does not poll, and it cannot see into systems that do not tell it anything. Before designing any automation, establish which of your process steps actually emit an observable event.

Observable today: content, media and member events; user events; form submissions via Umbraco Forms; commerce orders and stock changes; engagement signals via Engage; AI agent run lifecycle events; anything an external system sends to a webhook trigger.

Not observable without work: anything happening entirely inside another system that does not emit outward. For these you have three options to write a custom C# trigger, configure the external system to call an inbound webhook, or accept that the step belongs in a different tool.

Getting this wrong is the most expensive mistake available here, and it is a scoping failure rather than a coding one. The commercial version of this argument, including a project where we found the critical step ran outside Umbraco entirely, is covered in our companion article on the business case.

Production considerations

Filter your triggers. A content-published trigger with no content type filter fires on every publish across the entire site, generating run records for content you do not care about. Narrow it.

Plan for run history growth. Automate records data per step per run. Decide how long you need to retain it, compliance requirements may set the floor and manage it deliberately rather than waiting for the database to force the conversation.

Keep custom actions small. One action, one job. A large action doing six things is impossible to reuse, and it buries composition logic in compiled code where the business cannot reach it. That defeats the entire point of the tool.

Use connections for credentials. They exist so a key is stored once and rotated in one place rather than seven. Give each connection the minimum scope it needs in the target system.

Separate workspaces by function. Marketing, editorial and integration automations belong in different workspaces with different user group access. A junior editor should not be able to modify the flow that writes to the finance system.

Monitor from the dashboard. It surfaces failing automations, recent runs and pending approvals. Review it weekly during early adoption a failing automation nobody notices is worse than no automation, because the business assumes the work is still being done.

A sensible implementation sequence

Phase one: observe. Build read-only automations first log messages, internal notifications. Blast radius zero, while the team learns the canvas, bindings and run history on something that cannot break a customer journey.

Phase two: replace the fragile glue. Take the integration that breaks most often, rebuild it, run both in parallel for a fortnight comparing outputs, then decommission the old one.

Phase three: extend. Build the two or three custom C# actions specific to your stack. One-time cost, permanent capability.

Phase four: hand over. Train marketing and editorial on the canvas, keeping permissions tight and approval steps on anything customer-facing.

If you are on Umbraco 13 or earlier, Automate requires an upgrade first. It is a strong addition to the business case for that upgrade, but sequence the upgrade and the automation program separately rather than attempting both at once.

Summary

Automate gives you a real workflow engine running in-process, a small and readable concept model, a canvas that keeps composition out of compiled code, and three clean C# extension points with DI and typed settings. The constraints worth designing around are that it reacts only to observable events, and that run history grows with use.

For most Umbraco estates, the practical value is not a capability that was previously impossible. It is that triggers, actions, credentials, run history and approvals now live in one governed place instead of being scattered across a CMS, a middleware service and a third-party platform.

We at Giriraj Digital, is an Umbraco Platinum and Contributing Partner. If you are planning an Automate implementation and want a second opinion on the architecture, talk to our Umbraco certified team now!