Real-time and background workflows

What it does

Classic Dataverse processes built in the XAML workflow designer, running without a user interface. Background workflows run asynchronously when the platform has capacity; real-time workflows run synchronously and immediately, inside the operation. The choice is a single checkbox — Run this workflow in the background — set at creation.

Key facts

Created from a solution via New > Automation > Process > Workflow. Clearing the background checkbox makes it real-time.
Existing workflows are edited through Advanced settings > Processes, the legacy interface.
Background workflows execute as system jobs on the asynchronous service, so they're visible, pausable and reviewable in System Jobs alongside rollup and bulk delete jobs.
Real-time workflows run inside the transaction, which means a failure rolls the operation back and the user sees an error.
Custom workflow activities extend workflows with .NET code and run in the same sandbox as plug-ins, under the same 2-minute constraint per activity.
Custom process actions are built on this same engine, which is why they're not subject to the 2-minute limit end to end while an individual custom workflow activity inside them is.
Rollup column updates can't trigger a workflow, and a workflow wait condition can't reference a rollup column. Calculated and formula columns don't trigger workflows either.
Microsoft's guidance on the real-time workflow page is direct: "There are better ways to create modern automations. Consider using Power Automate flows." There's a dedicated article on replacing background workflows with flows.

When to use / skip

You don't build new ones. Everything a workflow does, a cloud flow or a plug-in does better, with better telemetry, better ALM and a designer that isn't from 2011. You still meet them constantly though — in any Dynamics 365 estate more than a few years old, in Dynamics-shipped managed solutions you can't remove, and hiding behind custom process actions. The one place a real-time workflow still earns its keep is a genuinely synchronous requirement that a functional consultant needs to own without a developer: setting a field or creating a related record inside the transaction, right now, with no code. Even then, weigh it against a real-time workflow's worse debuggability compared to a plug-in.

Configuration decisions

Whether the requirement genuinely needs to be synchronous, because that's the only decision that can't be revisited without rebuilding.
Scope — user, business unit, parent-child business unit or organisation — which determines whose records the workflow acts on and catches people out on large estates.
Whether the workflow runs as its owner or as the calling user, which is a security and audit conversation.
Whether to migrate an inherited workflow to a flow now, at the next release, or never. "Never" is a legitimate answer for stable logic that nobody touches.
For anything Dynamics 365 shipped: whether you're allowed to deactivate it at all, and what breaks if you do.

Gotchas

The background workflow overview page hasn't had a substantive content update since 2020. That's a fair signal about where the investment is, and about how much troubleshooting help you'll get from the docs.
Background workflows queue. Under load they run late, and "late" during month-end can mean hours. Users interpret that as the system being broken.
Real-time workflow failures surface to the end user as an error dialog on save, with a message they can't act on. Every one of those is a support call.
Deactivating a workflow to edit it stops it firing for the duration, and people forget to reactivate. Check the state, not just the definition, when something has quietly stopped working.
Workflows owned by a leaver keep running under that identity until the account is disabled, at which point they fail. This is the most common cause of "it worked last month".
Migrating a workflow to a flow changes the execution identity from the workflow owner to a connection owner. That's a permissions redesign, not a lift and shift.

Consultant notes

On any brownfield engagement, inventory the active processes before you promise anything. The list is always longer than the client thinks and about a third of it is doing nothing.
Don't propose a big-bang workflow-to-flow migration. Migrate what you're already touching, leave stable logic alone, and be honest that the business case for the rest is thin.
Warn the client that classic workflows have no meaningful run history compared to flows. When one misbehaves, the investigation is slower and more expensive.
If a client insists on real-time workflows because "plug-ins need a developer", make the total cost of ownership argument once, in writing, and then support their decision.

Worth revisiting if Microsoft ever publishes a retirement date — none has been announced as of July 2026.