Dataverse Classic Copy

Copy a Classic Workflow

Copy an existing Classic Workflow by promoting it to a Process Template, then creating a new workflow from that template — and restore the metadata that the template mechanism does NOT carry over.

⚠️ This is the supported way to clone a workflow in the legacy designer, but it has well-known gaps and a UI bug. Read this entire skill before walking the user through it.

When to use

• "I want to make a copy of this workflow so I can change it without affecting the original."
• "Clone this workflow as a starting point for a new variant."
• "I'm building a new version of an existing process — start me with a copy."
• "Make a workflow template I can spin new workflows off of."

If the user instead wants to edit the existing workflow in place, route to write-workflow. If they want to diff the copy against the original later, route to compare-workflows.

Critical context — what the template mechanism does and does not copy

When you convert a workflow to a Process Template and then "New ▸ from Template", only the steps, actions, and conditions copy across. Several trigger and execution settings are silently reset.

What DOES copy

• All workflow steps and their ordering
• Conditions and their branches
• Step display names and configured field values
• Custom workflow activity references
• VB.NET expressions inside steps

What does NOT copy (you must manually re-set these on the new workflow)

You MUST verbally walk the user through every one of these settings after they create the copy. The single most common mistake is publishing the new workflow with an empty trigger and wondering why it never fires.

Critical bug — converting a workflow to a Process Template

There is a long-standing bug in the classic workflow editor (the legacy process form, accessed from the solution explorer or via the "Switch to Classic" link from the maker portal):

If you switch a process from "Process" to "Process Template" in the classic editor and then click the "Activate" button in that same editor, the change is silently discarded — the workflow stays as a regular Process, not a Template.

The workaround (always use this sequence)

1. Open the workflow in the classic editor (legacy form).
2. In the "Activate As" dropdown (top of the form), change the value from Process to Process Template.
3. Click Save and Close (NOT Activate). The change is now committed to the workflow record.
4. In the Power Platform maker portal (make.powerapps.com), navigate to Solutions ▸ ▸ Processes, find the workflow, and toggle it to On (this activates it).
5. The workflow will now activate AND retain its Process Template status.

If the user reports "I switched it to a template but it's still a regular workflow", the cause is almost always that they hit Activate inside the classic editor instead of Save and Close + activate from the maker portal.

Outputs

• Pre-flight summary — the original workflow's trigger / scope / on-demand / child-process / run-as settings, captured so you can reproduce them on the copy.
• Step-by-step walkthrough — each click the user needs to make.
• Post-copy checklist — every setting they need to verify on the new workflow before activating.

Procedure

Step 1 — Capture the original's settings (BEFORE doing anything else)

Before promoting anything to a template, read the original workflow's metadata so you can faithfully re-create it on the copy. If you have the XAML locally, you can pull most of these from the <mxswa:Workflow> root attributes:

• Trigger="…" → which triggers were checked (a bitmask — see trigger-types.md)
• Scope="…" → User / BusinessUnit / ParentChildBusinessUnit / Organization
• Mode="…" → Background or RealTime
• RunAs="…" → Owner or CallingUser
• PrimaryEntity="…" → the table the workflow runs against

The "on-demand" and "child process" flags are stored on the workflow record (not in the XAML), so the user has to read those off the classic editor:

• On Demand: check "As an on-demand process"
• Child: check "As a child process"

If filtering attributes are configured (Trigger includes "Record fields change"), they live on the workflow record's triggeronupdateattributelist field. In the classic editor they appear as the field list next to the "Record fields change" checkbox.

Present the captured settings to the user as a checklist they can refer to after the copy. Example:

Original: "Account Onboarding Approval"
  Triggers:           Record is created, Record fields change (creditlimit, statuscode)
  Scope:              Organization
  Run As:             Owner of the workflow
  Mode:               Background
  On-demand allowed:  Yes
  Child process:      No
  Primary entity:     account

Step 2 — Convert the original (or a freshly imported clone) to a Process Template

If the user wants to keep the original active and unchanged, have them first export → import the solution under a new unique name, then promote that copy to a template. Otherwise this step turns the original into a template and it will no longer fire on its own.

In the classic editor:

1. Open the workflow.
2. If it's currently activated, click Deactivate at the top.
3. Change Activate As from Process → Process Template.
4. Click Save and Close. (Do not click Activate here — that's the bug described above.)
5. In make.powerapps.com, find the workflow under your solution and toggle it On to activate it as a template.

The workflow record now has category=2 (Workflow Template) and is available as a starting point under "New process ▸ from an existing template (select from list)".

Step 3 — Create the new workflow from the template

In make.powerapps.com (or via the legacy "New Process" dialog):

1. Solutions ▸ ▸ + New ▸ Automation ▸ Process ▸ Workflow (or in the legacy designer: New Process).
2. Give the new workflow a distinct name — never reuse the original name in the same solution.
3. Choose the same primary table as the template.
4. Under Type, choose "New process from an existing template (select from list)" and pick the template you just created in Step 2.
5. Click OK / Create.

Dataverse opens the new workflow in the classic editor with all the steps copied from the template, but none of the trigger / scope / on-demand / child / run-as settings.

Step 4 — Restore the trigger, scope, and execution settings

This is the step everyone forgets. Using the checklist from Step 1, set each of the following on the new workflow in the classic editor:

• Activate As: Process (not Template — this is the new working copy)
• Scope: match the original (User / BU / Parent:Child BU / Organization)
• Run As: Owner of the workflow vs Calling user
• Mode: Background vs Real-time
• Start When checkboxes: check each trigger from the original (Record is created, Record status changes, Record is assigned, Record fields change, Record is deleted)
• Filtering attributes: if "Record fields change" is checked, click "Select" next to it and re-add the same field list
• As an on-demand process: check if original had it
• As a child process: check if original had it

Click Save and Close.

Step 5 — Activate and verify

1. In make.powerapps.com, toggle the new workflow On to activate it.
2. Verify on a test record that it fires under the expected conditions.
3. If it doesn't fire: 9 times out of 10 the trigger or scope is still wrong. Re-open in the classic editor and recheck against the Step 1 checklist.

Step 6 (optional) — Pull the new workflow XAML into source control

If the user wants to track the copy in their repo:

pac solution clone --name <SolutionUniqueName> --outputDirectory "<solution-folder>"

The new workflow will land at <solution-folder>/src/Workflows/<NewDisplayName>-<workflowId>.xaml. At this point you can hand off to read-workflow or write-workflow for further work.

Common gotchas

Don't

• Don't promote the original workflow to a template if you still need it to run. Templates do not fire on their own. Either deactivate-and-keep for reference, or import a separate copy of the solution first and promote that to a template.
• Don't click Activate from inside the classic editor when switching to Process Template. Always use Save and Close + activate from the maker portal (the bug described above).
• Don't trust that "all the important stuff copied". It didn't. The trigger, scope, on-demand flag, and child-process flag are all reset. Walk the checklist every time.
• Don't auto-fill the new workflow's settings without first asking the user to confirm the original's settings. Some teams intentionally change Scope or Run As when forking a workflow — don't assume.
• Don't generate a new workflow GUID and try to inject it into the XAML file directly as a "copy". The supported path is the template mechanism above; manual GUID-and-name munging will produce a workflow the platform can't manage cleanly (broken solution layering, missing workflow-record metadata).