Real-time vs background workflows in Dataverse

A classic Dataverse workflow runs in one of two modes — real-time (synchronous) or background (asynchronous). The same workflow definition behaves quite differently in each mode; the choice matters for transaction semantics, performance, and operational behaviour.

Real-time workflows.

A real-time workflow runs synchronously as part of the same Dataverse transaction that triggered it:

• The user (or API call) initiates an operation (Create, Update, Delete, etc.).
• Dataverse runs the operation.
• Real-time workflows registered to fire on that event execute inside the transaction.
• Any errors in the workflow can roll back the entire transaction.
• The user / API caller waits for the workflow to complete before getting the response.

Implications:

• Transactional integrity — workflow logic that fails rolls back the originating operation. Use case: a workflow that validates customer credit before allowing an opportunity to advance can refuse the operation by raising an error.
• Synchronous execution — the user pays for the workflow time. Slow workflows make the UI feel slow.
• Latency contribution — every real-time workflow adds latency to its trigger event.
• Error visibility — workflow errors surface immediately to the user.
• Cannot use wait conditions — synchronous execution can't pause indefinitely.

Background workflows.

A background workflow runs asynchronously after the originating operation:

• The user initiates the operation; Dataverse processes it.
• Background workflows queue for later execution.
• A separate execution thread picks them up and runs them.
• Workflow errors are logged to the workflow history but don't affect the original operation.

Implications:

• No transaction rollback — the originating operation already committed; the workflow can't undo it.
• No user-visible latency — the originating operation completes immediately.
• Eventual consistency — there's a delay between the originating operation and the workflow's effects.
• Wait conditions supported — workflows can pause for hours or days waiting for conditions.
• Failure handling — failed workflows can be retried automatically or surfaced in the workflow log for investigation.
• Higher throughput — many background workflows process in parallel.

Choosing.

Use real-time when:

• The workflow is fast (milliseconds).
• Errors in the workflow should roll back the originating operation.
• Synchronous data integrity is essential.

Use background when:

• The workflow takes more than a fraction of a second.
• Wait conditions, delays, or polling are involved.
• The workflow makes external calls (API, integration).
• The workflow is part of an asynchronous business process.
• Errors should be recoverable but not block the original operation.

Real-time workflow caveats.

• Avoid external API calls — adds unpredictable latency to user operations.
• Avoid heavy logic — substantial computation slows the user experience.
• Be careful with side effects — modifications cascade through other triggers and other workflows.
• Test under load — real-time workflows that work at low volume may bottleneck at scale.

Background workflow caveats.

• Queue backlog — heavy background workflow load can produce queue delays. A workflow that "should fire immediately" might fire minutes later if the queue is full.
• No automatic compensation — if a background workflow needs to roll back its effects, you must write compensation logic explicitly.
• Wait state cleanup — workflows with wait conditions sitting indefinitely consume resources. Clean up abandoned waits.

The Power Automate parallel

The same dichotomy applies to Power Automate flows:

• Instant flows triggered synchronously in a UI context — equivalent to real-time.
• Automated flows triggered on Dataverse events — typically asynchronous, equivalent to background.

Modern Dynamics 365 implementations use Power Automate for most asynchronous orchestration; classic background workflows survive for legacy logic; real-time classic workflows survive where in-transaction semantics matter.

Monitoring.

• Real-time — failures surface to users immediately. Application Insights captures the trigger context.
• Background — workflow history table records every execution with status. Long-running queues need active monitoring.

Common pitfalls.

• Wrong mode chosen — real-time workflow doing heavy work slows the UI; background workflow doing critical validation lets bad data slip through.
• External calls in real-time mode — API timeouts make the UI freeze.
• No queue monitoring for background workflows — workflows pile up unnoticed.
• Wait conditions abandoned — stuck waits consume resources indefinitely.

Operational reality

For new logic, default to Power Automate (typically asynchronous). For existing classic workflows, audit which should be real-time vs background based on what the logic actually requires. Mode mismatches are one of the most common workflow performance and behaviour issues.