- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
10-24-2022 02:28 AM - edited 03-11-2025 05:22 AM
Workflow Automation CoE > Migration FAQ
What is the modern Workflow Automation toolkit?
Workflow Automation encompasses our workflow builders to create playbooks, flows, subflows, flow actions, and decision tables. These can be created and edited either in Workflow Studio or natively in ServiceNow Studio. Additionally, Citizen Developers can create simplified playbooks or flows in Creator Studio in a tailored and guided development environment.
How should you migrate?
Check out this comprehensive guide on legacy workflow migration, which includes a project outline, resources, and good practices when migrating legacy objects on the Now Platform.
What should you migrate?
As much as possible, as little as necessary. As of the Xanadu release, we have no plans to turn off the legacy workflow engine, so whatever is running today, can keep running for the time being. However, there are tangible benefits to development, performance, (re)useability, and security when using the latest toolkit over legacy technology. If we decide to start the official deprecation process, all customers will be notified ahead of time, according to the deprecation process published in this KB0867184.
Why should you migrate?
The legacy Workflow Editor - while still supported - has entered maintenance state. It has not received any updates or enhancements since 2018. All new development, features, and enhancements are for the modern Workflow Automation toolkit, and that includes flows, subflows, flow actions, playbooks, decision tables, all built in Workflow Studio or ServiceNow Studio.
Useability and debugging
Workflow Studio brings all workflow artifacts into one single builder with useful execution analytics and all properties and settings at your fingertips. Testing and debugging a flow or subflow and being able to easily add robust error handling is a vastly better experience than trying to add debugging or logging to legacy workflows or scripting. You can run tests directly from the builder without the need to create and recreate test records in other browser tabs.
Custom flow actions are more easily discoverable and reusable than functions in Script Includes or Scripted REST integrations. The ever-growing catalog of available Integration Hub spokes significantly reduces the need for custom integrations and time to value when integrating with third-party systems.
Native step annotations and action or subflow descriptions allow for your peers to easily understand what your automation is designed to do.
Flows and Playbooks both offer a fully functional diagram view as well as a linear flow view and a Kanban-style playbook view respectively between which you can freely toggle back and forth and choose the view that you like best.
Low-Code Accessibility
Security features and access limitations like Feature access and Content filtering allow you to invite citizen developers into creating business logic. Build trust between pro and low coders by establishing technical guardrails so they do not accidentally delete data or use integrations they should not.
Learn how to use the access control and security features on the application, builder, and execution level in this article series and video:
https://sn.works/CoE/SecureWorkflows
Access to more tools and latest innovations
Additionally, adopting the modern workflow toolkit allows you to natively use other modern tools like decision tables, Integration Hub spokes, integrate with Virtual Agent conversations and start using the newest Generative AI innovations in Now Assist for Creator, including the Now Assist skills for Flows and Playbooks. Additionally, flows are tightly integrated with Robotic Process Automation (RPA), allowing you to launch flows and subflows from RPA automation, as well as launching RPA robots from flows or subflows to integrate data from legacy systems or systems where APIs are not accessible.
Reporting and Data Consumption
Workflow writes a wf_context record to track every execution. As the workflow executes, it also writes many records to the database to track the progress, history and transitions between each step. While highly optimized, each write to the database comes at a performance cost. Reporting cannot be turned off for Legacy Workflow.
Flow Designer writes a sys_flow_context record (unless the QuickAPI is used to initiate the flow). If reporting is enabled, the flow engine passively writes to a reporting table, the flow execution details. Flow reporting is highly optimized to have as little impact on execution performance as possible. While execution performance impact is minimal, flow reporting does consume significant disk space (database space) and should NOT be used for high volume use cases.
Performance
Lastly, and most importantly, the flow engine has been designed and reworked for performance.
Legacy workflows run synchronously by default, which means they will run in the user thread, holding up the user session until the workflow is finished or goes to sleep via a pause or wait for condition event. While instant execution is good, it comes at a cost to the user if initiated from a user thread.
Customers often add a one-second wait at the beginning of a legacy workflow, pushing the execution into the background and handing control back for the initiating thread (often the user thread) for continued processing. This also places an event in the sysevent queue for scheduled worker threads (running every 2-8 seconds) to continue in a system thread. This 'pause’, and queuing delay the completion of legacy workflows.
Unlike legacy Workflow, Flows can be configured to run synchronously (foreground) or asynchronously (background). By default, Flows run in the background, so they do not affect the calling thread.
Flow engine uses NowMQ, an in-memory queue for asynchronous processing. NowMQ picks up asynchronous executions in under ½ second and does not require a scheduled worker job to read from sysevent. This allows asynchronous flows to start nearly as quickly as synchronous flows, without impacting the initiating thread. Flows also support prioritization (medium by default), allowing high priority flows to run even if there are medium or lower priority flows earlier in the queue. Synchronous is still available for instance execution but should be used judiciously.
Then why is ServiceNow still shipping workflows?
That is an excellent question, and one we are prepared to answer with “No, we don’t” by the Zurich release. Our product teams have so far migrated 540 legacy workflows for the Yokohama release, and our own migration project is on track to be completed by the Zurich release with Customers will still be able to run their existing workflows, but we will have replaced all workflows that are included in ServiceNow products as of the Xanadu release with new automation using flows and playbooks.
More Resources
Learn more in our Academy Session about Flow Designer Migration Use Cases and these blog posts:
How to migrate from scripted integration to Integration Hub
Is your work flowing? What makes Flow Designer and IntegrationHub better and why you should migrate ... (Release: Rome)
Center of Excellence Navigation
- 5,369 Views
