RFC: Replacing Forms Workflows with Umbraco Automate?

[Amalie-Wowern]

We are exploring whether Umbraco Automate should replace Workflows in Umbraco Forms. Nothing is decided, and there is no proposed solution yet. Before we go further, we want to hear how you use Forms Workflows today and what would worry you about a change.

Background

Forms Workflows run actions when a form entry is submitted, approved or rejected. Umbraco Automate, launched in July 2026 for Umbraco 17+, is a general automation engine with triggers and actions across products, and already has a "Form Submitted" trigger.

	Forms Workflows	Umbraco Automate
Scope	Umbraco Forms only	Forms, Commerce, Engage, CMS and custom
Starts on	Submit, approve or reject stage	Triggers, e.g. Form Submitted, Order Created, Persona Scored
Logic	Ordered steps per stage, field-based conditions	Paths, loops, if-statements, switches, approval steps
Built-in actions	Email, email with template, Slack, post to URL, save as content node, XML, change record state	Not limited to Forms; can call AI agents
Can change the stored entry	Yes, submit-stage workflows run before the record is saved	Open question
Editor UI	Workflow list per form stage	Drag-and-drop canvas in the backoffice
Extending	Custom workflow types in C#	Custom triggers and actions in C#, webhooks, API
Monitoring	Audit trail per workflow with retry	Open question

Sources: Attaching workflows, Workflow types, Adding a workflow type, Launching Umbraco Automate.

Why we're asking

Three reasons drive the question:

• One automation engine. Today automation lives in several places. One engine means one set of concepts to learn and maintain.
• A consistent experience. Editors and developers would build form automations the same way as automations for content, Commerce and Engage.
• More capabilities. Automate supports branching, loops, approval steps and triggers from other products, which Forms Workflows do not.

We also know Forms Workflows are used on many sites, and that a change could cost you time. That is why we are asking before deciding anything.

What we'd like to hear from you

Answer whatever applies to you. Examples from real sites help us more than yes or no.

Who works with form workflows today

• Who sets up and changes workflows on your sites: editors, developers, or both?
• If editors work with workflows, what do they use them for? What do they find easy or hard?
• Tell us about a form workflow you rely on. What does it do, and why does it matter?

Where form automation should live

If form automation moved to Automate, it could live in the Automate section, inside Forms, or both. We have not decided, and we can't promise any of these options.

• How would your editors feel about setting up form automation in a separate Automate section?
• Would they expect to see or start an automation from the form itself? What would they need to see there?

What would need to be true

• What would Automate need to do before it could take over your form workflows?
• What do you do with Forms Workflows today that you would worry about losing?
• If you have tried Automate, what was your experience?

Concerns about a change

• What would make a move feel safe for you, your editors and your clients?
• What would a move cost you, and what would help?

How to respond

Reply in this discussion. Answer any questions that apply to you, and share examples where you can. We will summarize what we hear in this thread before deciding on any next step.

[iOvergaard]

Thanks for asking before deciding. One data point that may help: since late October I've had form handling on a small bilingual site (Danish and German) running entirely on Automate. It doesn't use Umbraco Forms. The site's own forms publish a notification, a custom "form submitted" trigger picks it up, and every email is a step on the canvas. So it isn't a migration story, but it's close to what a move from Forms to Automate would look like, and the gaps showed up quickly.

The flow I rely on. A booking request triggers two emails: a notification to whoever manages that booking, with Reply-To set to the visitor, and a confirmation to the visitor in their own language. The site keeps no copy of the submission, so Automate's run history is the only record that it arrived. That's why the monitoring points below matter to me.

What worked well. The canvas and the binding picker make the flow easy to follow, and the run history shows exactly what each step received. Building the custom trigger was straightforward. Automate found it by its attribute and wired up the notification handler itself, so the site only had to publish a notification.

What I had to build to match what a Forms workflow email does today

• Email with a layout. The built-in Send Email sends the body as it is, so a custom action wraps it in the site's header and footer.
• Localisation. The guest confirmation has to go out in the visitor's language. The trigger exposes the submission's culture, and the wording lives on culture-variant content nodes, falling back to the default language when a translation is missing.
• Reply-To, CC and BCC. Reply-To was missing. All three have since been added upstream (feat(action): Let Send Email set Reply-To, CC and BCC addresses Umbraco.Automate#486).
• Encoding. Bindings are filled in raw, so whatever the visitor typed goes straight into an HTML email body. I added an htmlEncode filter, plus a check that refuses to publish an automation whose email body uses a visitor value without it. For Forms, where every field is untrusted input, I think this needs to be built in rather than left to each site.
• Recipients from data. The notification goes to an address stored on a content node that the submission refers to, which needed a custom lookup.
• Spam. Honeypot hits are excluded at the trigger by default, so no automation has to remember to filter them. I get a lot of spam and don't want to pollute the Automate run history with verified spam; only the potentially false positives get logged.

Who sets it up, and who may
On my site, the developer builds the automations and the editor only edits the email texts, which are ordinary content nodes. That split works well because the editor never needs the Automate section at all. More generally, Forms and Automate are separate sections today, and that difference matters:

• The people who set up form workflows are often not the people who should touch every automation on the site, such as ones that publish content, call external services or move Commerce orders.
• Today, giving someone a form's workflows doesn't give them anything else. If form automations move into Automate, I think that needs to stay true, with access scoped to a form or to a group of automations rather than all or nothing.
• Automate already groups automations into workspaces, each running as its own service account. Could that be the boundary, so a Forms editor sees and edits only the form automations?
• Either way, it should be possible to see from the form itself which automations it triggers. Otherwise someone changing a field can't tell what they might break.

On the open question of monitoring
The run history works well as an audit trail. A few things surprised me, though:

• Retries default to 10 attempts, 30 seconds apart, with no backoff.
• A run that succeeds on retry is still recorded as Failed and counts towards the circuit breaker.
• While Automate runs its migrations at startup, its outbox drops messages with only a log warning, so a submission that arrives during a restart gets no run. With Forms, the stored entry would still be there, but anyone relying on Automate alone loses it.

Data and deployment

• The run history keeps the trigger payload and each step's resolved input (name, email, message). The defaults are 90 days and 1,000 runs per automation. Alongside a stored Forms entry, that's two copies of personal data with different retention, which would need a clear story for GDPR.
• Automations live in Automate's own tables, not in source control. They move between environments with export/import, and content and API users they reference have to be picked again when keys differ. Today a workflow travels with its form, so I'd want to know how that maps.

Extension points
Two things I relied on aren't documented. One is the evaluator that fills bindings outside a step. The other is reading the automation from the publishing notification, which I can only do by reflection. Custom Forms workflow types would likely need both, as public and documented APIs.

In short, before Automate could take over form workflows for me, it would need: templated and localised email out of the box, visitor input encoded by default, access that can be scoped to form automations, and no submissions lost during a restart.

[justin-nevitech]

From my experience, it's the developer that set's up the Workflows initially, but then the client may amend them over time (i.e. change email recipients, etc). For most forms, the Workflows probably don't change at all or that often. That said, we don't often check or review forms on live sites so some heavier Umbraco Forms users may create forms and workflows themselves (or at least copy existing forms and adapt).

My concern though would be migration - both of Workflows themselves and any custom Workflow steps using code. If you do drop Workflows in Umbraco Forms, the migration path has to be a smooth as possible with either automated migrations of the Workflows themselves to Automate and good clear docs and steps on how to migrate the code.

We would still need a way to migrate Workflows attached to forms through environments regardless.

[liamgold]

I work at an agency that builds and supports Umbraco sites with Forms for a range of clients, and I also build on Xperience by Kentico, so I can give a bit of context on how Kentico handles the same thing.

Firstly - I think cutting down duplicated functionality is the right direction, so I am leaning towards this being the right move.

Thinking from an end client's perspective though: if I'm paying a subscription for Forms, it could look like a feature I'm paying for is being taken away. It would still be there through Automate, but clients might pick up on this, and they might worry that Automate becomes a paid add-on later. Just throwing that out there 😅

Thinking ahead to upgrades, if/when Forms Workflows are dropped in favour of Automate, I think there should be a migration tool or an AI agent skill to help move existing workflows across, so the transition is part of the upgrade rather than a manual rebuild.

Xperience by Kentico has a single automation engine, but it keeps a light layer on the form:

• On the form: editors can set up a basic autoresponder email to the visitor. Most forms probably only need this, to say thanks for submitting etc. Very easy for marketers/editors to create without having to build a flow.
• In Automation: anything complex or multi-step, such as conditions, waits or a series of emails. Automate already covers this with its visual builder. Developers add custom triggers, actions and conditions in C#. This is where I think Umbraco differs, as Automate feels more developer focused, whereas Kentico's automation is marketer focused - I wrote a blog post on this bit in particular.

Something similar could work well here: keep simple notification and confirmation emails on the form, and hand anything more complex to Automate.

[bstephenson-idhl]

To add to this. With XbyK, the workflows that Liam's mentioned here are for async ones. The widget where users add forms on to the page is where they can configure what end users see on submission (Thank you or Redirect). This can be configured differently for the same form on different pages.

[CarlSargunar]

Echoing Liam, 2 different types of workflow are not the way to go with this, so kepeing it consistant and one way of doing it is definitely the right way forward. There will absolutely need to be a tool or skill to migrate between the two.

I'd consider how this is packaged - and how much rework this will require to anyone extensively using forms workflows, and custom workflows, which will almost certainly require rebuilding.

[moriyama-nik]

My initial question is.. "If I just want to use Umbraco Forms, why do I need to install Umbraco Automate" ?
So from a developer perspective understanding how the two packages would combine/relate to each other becomes a key part.

Next - the majority of workflows for Umbraco forms, make sense to sit in Umbraco Forms where they currently are. On occasion if the work flow gets to complicated, then maybe it could do with it's own space.

We have a mix, in smaller clients, dev's often create the workflows and minor settings on them get changes, but on our larger clients, they are creating new forms and workflows monthly, changing copy in some of them, changing destinations, adding new steps. Configuring field mappings for uploads. All sorts of different processes so the reality is "it depends".

Personally my view is:

1. A "Shared automate library" ships with Umbraco Forms
2. Existing workflows need a mechanism for becoming the new "Automate Forms Workflow"
3. Editing of a Forms related workflow (being either classic or Automate) should stick with the forms, having to go somewhere else to set it up/manage it would be a very jarring experience if you are already on the form - keep it easy for editors
4. If "Full automate" is also installed, it should be possible to see the Forms workflows in full automate as well
5. This should be proposed as "Modernising the Umbraco Forms Workflow Engine" rather than "Replace Umbraco Forms Workflow with Automate". Even if this is what is happening under the hood, from a UI/Editor experience it should not be as blatant as that that for the point Liam raised about perceptions.

Question - Would this make a workflow/automation built in Automate re-usable across multiple forms while maintaining the ability to customise elements of the steps - for example a simple workflow might be to send two emails, one to the customer, and one to the client. But for each form it's applied to, the email field alias on the form might be slightly different, the subject would need to change, possible even some of the body text, the client email address might need to be different as well. So a way of overriding "configs" would be needed is this was a proposed feature of this new approach.

[NurhakKaya]

I have extensively worked with Umbraco Forms and custom workflows and found Umbraco Forms Workflows to be very helpful in my projects. Managing workflows directly within the forms is convenient.

Our technical team usually creates custom workflows since they often require code changes and connecting to other systems. Clients typically use the built-in workflows for simple tasks, but some skilled clients make their own complex workflows.

Some clients would likely argue that moving to Umbraco Automate would result in losing existing features on Forms. It would be important to justify the changes to the clients and a simple migration pathway would help us a lot.

I believe we will be more open to using Umbraco Automate for workflows after we start using it in our live projects.

[SimonAntony]

We've built on Umbraco Forms since the v4 days and still run it across client sites up to v17, with a lot of custom workflow types along the way. I agree that having one automation engine makes sense long term. But a lot of what we rely on depends on how workflows behave today, not just on what they're able to do, so here are the things I'd need answered before moving anything.

What we rely on

[Example 1 - e.g. a custom workflow that pushes submissions into a client CRM/ERP, maps fields, handles auth and failures. What it does and why the client depends on it.]

[Example 2 - e.g. a submit-stage workflow that enriches, sanitises or strips data before the record is saved.]

1. Changing the record before save

The comparison table lists this as an open question. For us it's a hard requirement. Submit-stage workflows that run before the record is stored are how we keep sensitive data out of the database, normalise values and add reference numbers. If Automate only ever sees the entry after it has been persisted, that's a step backwards for data minimisation, not a like-for-like swap.

2. The visitor waiting on the result

Some submit workflows have to finish while the visitor is still on the page. Their result decides what the visitor sees next, or whether the submission is accepted. As I understand it, Automate runs through an outbox, after the fact. A form submission is a moment you can't replay, so "eventually, probably" isn't good enough for some of these. We'd need a clear line between workflows the visitor waits on and ones that run in the background, with both supported.

3. A compatibility layer for custom workflow types

Others have asked for migration tooling for configured workflows. The bigger cost for us is code. We have a lot of custom WorkflowType implementations. An adapter that lets an existing WorkflowType, with its [Setting] attributes, run as an Automate action without changes would turn this from a rewrite into an upgrade. We'd rewrite them properly over time, but not all at once on an upgrade deadline.

4. Deployment

Workflows travel with the form definition today, so they go through our normal deployment flow (Deploy on Cloud, uSync elsewhere). Automations stored in their own tables and moved by export/import, with keys re-picked by hand, is a regression for anyone with a proper deployment pipeline. The form and its automations need to move together, in source control.

5. Editors

The pattern on our sites matches what others have said. We build the workflows, and clients change recipients, subjects and copy. That should stay on the form. Sending editors to a separate section with a full canvas to change an email address adds risk and support calls, and gives them nothing in return. moriyama-nik's idea of reusable automations with per-form overrides would cover most of our cases neatly.

6. Timeline

Automate is v17+ only, and there are still plenty of v13 sites around. Whatever happens, I'd want classic workflows supported alongside Automate for at least one full LTS cycle after Automate reaches parity, not deprecated when the first migration tool ships. I'd also want "parity" defined up front, in this thread, so we can plan client budgets around it.