Process designer and classic workflows in Dataverse

Before Power Automate became the cloud-flow standard, Dynamics 365 had classic workflows — a configuration-based, code-light workflow engine running inside Dataverse. The classic engine still exists, still works for many scenarios, and is what some standard Dynamics 365 features still use internally. But Power Automate has substantially superseded it for new build.

Classic workflow basics.

A classic workflow is a Dataverse-internal process that runs on:

• Record events — create, update of specific fields, delete, status change, assignment.
• Scheduled trigger — periodic execution.
• On-demand — invoked manually by a user.

Each workflow:

• Has a scope (User, Business Unit, Parent: Child BU, Organization).
• Runs as synchronous (real-time, in the same transaction) or asynchronous (queued for background execution).
• Contains a sequence of steps — actions to take.

Available step types.

• Create Record — generate a new record (e.g. create a follow-up activity when a case is created).
• Update Record — modify the current or related record.
• Send Email — generate an email using a template.
• Start Child Workflow — recursive composition.
• Assign Record — change ownership.
• Change Status — modify status / status reason.
• Wait Condition — pause until a condition is met (asynchronous workflows only).
• Conditional branches — if-then-else logic.

Designed in the Process Designer. The visual designer (originally for Dynamics CRM, evolved into the modern process designer in the maker portal) provides drag-and-drop construction. Each step is configured with field-bound expressions and conditions.

Common historical use cases.

• Welcome email when a lead is created.
• Auto-assign cases to queue based on attributes.
• Status change cascades — opportunity won → create a follow-up task.
• Field defaulting beyond what business rules support.
• Inactivity timers — escalate cases after N hours.

Many of these patterns still work; many have migrated to Power Automate equivalents.

Why Power Automate has superseded most classic workflow.

• Connector library — Power Automate connects to hundreds of external services; classic workflow is Dataverse-internal.
• Visual designer — Power Automate's designer is more modern and approachable.
• Versioning and ALM — Power Automate flows live in solutions and version cleanly.
• Error handling — Power Automate has better retry, error, and parallel branch handling.
• Monitoring — Power Automate run history is rich; classic workflow logs are basic.
• Microsoft strategic direction — investment is in Power Automate; classic workflow is in maintenance.

Where classic workflow still matters.

• Synchronous in-transaction logic — classic synchronous workflows run inside the Dataverse transaction. Power Automate flows run asynchronously after the transaction commits. For logic that must succeed-or-fail with the originating operation, classic synchronous workflows have an advantage.
• Legacy customisations — existing workflows that work fine; migration cost may not be worth the benefit.
• Some standard Dynamics 365 features still implement internal logic as classic workflows (e.g. some Quote → Order conversion patterns).
• Real-time field updates — quick synchronous workflow updates can be more performant than Power Automate at very high volume.

Migrating from classic to Power Automate. Microsoft provides migration tooling — point at a classic workflow, generate a Power Automate flow template that approximates the same behaviour. Often requires manual refinement. Migration patterns:

• Simple "on create, do X" workflows → straightforward Power Automate trigger flow.
• Workflows with wait conditions → Power Automate flows with delay actions.
• Multi-stage workflows → Power Automate with multiple steps.

For workflows that mix simple logic with classic-workflow-specific behaviour (synchronous in-transaction needs), the migration to Power Automate may not preserve semantics — careful review needed.

Inventory existing classic workflows. Before migration:

• List every active classic workflow in the environment.
• Document its purpose, trigger, scope, status.
• Assess: is it still needed? Can it be retired? Should it migrate?
• Plan migration over time — don't try to migrate all at once.

Common pitfalls.

• Migration assumed automatic — the tooling produces a starting point, not a finished migration. Validate behaviour.
• Forgetting that classic workflows aren't being invested in — building new classic workflows when Power Automate would serve better.
• Synchronous vs async confusion — replacing synchronous classic workflow with async Power Automate changes transaction semantics.

Operational reality. For new functionality, default to Power Automate. For legacy classic workflows, retire when convenient; don't force a fragile migration. The two coexist cleanly; gradual modernisation is the practical path.