Converting Legacy Workflows with Build Agent - Workflow Automation CoE

[Lisa Holenstein]

Workflow Automation CoE > Converting Legacy Workflows with Build Agent

Goal

In this article, you'll learn about the Export Workflow UI Action on Workflow Version records, now available out-of-the-box as of the Brazil release, and how to use that XML export as a starting point for Build Agent to plan your conversion to a modern Flow or Playbook.

Technology

Workflow Studio is our central, low-code automation builder that consolidates Flow Designer, Process Automation Designer, Decision Builder, and Action Designer into a single design environment. Build Agent, available in ServiceNow Studio, can read your live platform context, so it's a natural fit for planning what a legacy workflow should become.

Component	Purpose
Workflow Editor	The Workflow Editor is an interface for creating and modifying workflows by arranging and connecting activities to drive processes. Note: These workflows are considered legacy technology and have not received new features and enhancements in over 9 years. Customers are strongly encouraged to use Workflow Studio to create process automation content instead.
Export Workflow UI Action	Exports a Workflow Version to XML; available out-of-the-box on Brazil
ServiceNow Studio	Use ServiceNow Studio to build, manage, and deploy custom, base system, or global applications and global metadata records from a single development environment.
ServiceNow SDK	Create and develop applications in source code locally in Visual Studio Code Desktop and upload changes to an instance using the ServiceNow software development kit (SDK).
Build Agent	Build Agent is an autonomous AI agent for creating and updating ServiceNow applications. You can also ask Build Agent general ServiceNow development questions.

Instructions

Use Case

There's no native, 1:1 converter from legacy Workflow Editor to Flows; the two are built on fundamentally different architectures. What does work well: export the legacy workflow to XML and hand it to Build Agent, which can analyze the logic in context and help you plan, or directly generate, the equivalent Flow or Playbook. As of Brazil, getting that export is quick: once you have the right role, it's just a few clicks.

Steps

1. Grant the workflow_admin role to the developer. The Export Workflow related link is only shown to users who pass the condition gs.hasRole('maint') || gs.getUser().hasAssignedRole('workflow_admin'). Because hasAssignedRole() checks for an explicitly assigned role, this applies even to admins. Log out and log back in for the new role assignment to take effect.
2. Navigate to Workflow => Administration => Workflow Versions from the Application Navigator or use wf_workflow_version.list as a shortcut.
3. Open the legacy Workflow Version record that you want to migrate.
4. Find the Export Workflow related link. It sits alongside Show Workflow and Validate Workflow in the Related Links section of the form.
5. Click Export Workflow and download the XML. This is your source material for the next step.
6. Hand the XML to Build Agent. Prompt it, from ServiceNow Studio or your ServiceNow IDE, to analyze the legacy logic and propose a conversion plan. Because Build Agent has access to your whole platform, it can go a step further and generate the new Flow or Playbook directly.

Tip: Running an earlier release? The Export Workflow UI Action has existed on wf_workflow_version for a while; it's just a visibility condition standing between you and the same export.

Example Prompt for Build Agent

Use the prompt below as a starting point and adapt the [bracketed placeholders] to your environment. Build Agent analyzes the XML export, returns a plan along with any questions, and waits for your confirmation before it builds anything.

Prompt: Analyze, plan, and convert

I'm migrating a legacy ServiceNow Workflow Editor workflow to a modern Flow or Playbook in Workflow Studio. Attached is the XML export of the Workflow Version (exported via the Export Workflow UI Action on wf_workflow_version).

Please:
1. Parse the XML and describe the workflow's logic in plain language: stages, activities, conditions, approvals, notifications, and any embedded scripts (e.g. script includes, run script activities, conditions using business rule logic). Don’t forget to describe loop back or unusual pathing of connecting lines.
2. Identify the workflow's trigger: what table, condition, and insert/update context starts it. Call out if a specific trigger is not available. Consider flow triggers for applications to match specific use cases like SLA or Service Catalog.
3. Map each legacy activity to its closest Flow or Playbook action equivalent (for example: Approval activity -> Ask for Approval action; Run Script -> Custom flow action).
4. Map the workflow's logic and pathing to flow logic: unconditional branching or parallel paths -> "Do the following in parallel" flow logic; conditional branching (If/Switch) -> Decision Table or if-then-else flow logic; conditional loop-back paths -> "Go back to" or "Do the following until" flow logic combined with if-then-else logic.
5. Flag anything that has no direct equivalent or needs custom handling: complex scripted conditions, custom GlideRecord logic, or activities calling other workflows. Stop and ask me how to proceed on these instead of guessing.
6. For Script activities, consider creating a flow action with a script step and appropriate inputs and outputs.
7. Recommend whether this should become a Flow, Subflow, or Playbook, and why, based on whether a human needs to interact with the record across multiple stages.
8. If you recommend building a Playbook, generate a BPMN process diagram that represents the legacy workflow (stages, activities, decisions, parallel paths, and loop-backs) so it can be used to build the Playbook's stages and activities when you build it. Optionally, provide the diagram as MermaidJS code that I can download or copy.
9. Use our existing naming convention: [insert naming convention, e.g. "[Team] - [Process] - [Flow/Playbook]"].
10. Place it in the [application name] application scope.
11. Produce a structured conversion plan (table format: Legacy Activity | Equivalent in Flow/Playbook | Notes/Risks) that I can review before you build anything.
Ask me any clarifying questions, and do not create or modify any records until I have reviewed the plan and confirmed. Once I confirm, build the recommended Flow, Subflow, or Playbook in Workflow Studio, matching the trigger table and condition of the legacy workflow as closely as possible. When done, summarize what was built and list anything that still needs manual configuration or testing before activation.

Conclusion

In summary, while there's still no native, 1:1 path from legacy workflows to flows, in a world of LLMs and tools like Build agent, you don't need one to get started on a migration. Three takeaways:

1. Architecture differences, not missing effort, are why a direct converter doesn't exist; legacy workflows and flows are built on fundamentally different models.
2. As of Brazil, the Export Workflow UI Action is available out-of-the-box on Workflow Version records, no workaround required.
3. Build Agent can take that XML export and run with it, analyzing the legacy logic to plan, or directly generate, the equivalent Flow or Playbook.

Tip: Build Agent is the default choice for this conversion because it has direct access to, and knowledge of, your platform. If you prefer another LLM, you can also do the same AI-assisted conversion from the Visual Studio Code Desktop application using the ServiceNow SDK.

I hope this was helpful! If you've tried an AI-assisted workflow migration yourself, drop your experience in the comments below.

Center of Excellence Navigation

1. Workflow Automation - Center of Excellence
2. Workflow Automation Migration Considerations
3. What's new for Workflow Automation?
4. Resource Hubs
   1. Flows
   2. Decision Tables
   3. Playbooks
5. FAQ
6. Checklist
7. Training
8. Workflow Academy