- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-23-2024 12:15 PM - edited 02-23-2024 12:17 PM
I'm trying to move an existing claim workflow into ServiceNow. In our old system a user starts the request and the entire form is visible. Steps to be completed later in the workflow are not writable but can be seen. Once the writable fields are completed the form is submitted for a data entry step by the claims department. After that the claim goes to a manager for initial approval. Once that approval is received another data entry task is assigned. Once that step is complete there is one more data entry step before the claim and workflow are completed.
I've recreated the form as a service catalog item and also created a workflow. In that workflow there are tasks assigned for the data entry steps required later in the workflow. I'm able to add the data entry variables to the tasks where needed and everything seems like it should work. I assigned the new workflow to the new service catalog item for testing. In the initial test all fields on the form were writable including the required data entry steps that can't be performed until later in the workflow. This meant I couldn't submit the form. What's the normal practice for a process like this? Being able to define the variable data entry on a task seems the correct way to do it but I appear to be missing something that more closely ties the item and workflow to work together.
Solved! Go to Solution.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-24-2024 09:39 AM
Hello @Alan42 ,
Is there any particular reason for you to build this whole thin in the Legacy Workflow instead of Flow Designer?
As for the approach itself, you are correct, you should split the actual job into tasks, where you show only the variables that are supposed to be filled by the fulfiller of this task.
Then, using Catalog UI Policies you can control the behavior of the fields (Mandatory, Visible, Read-Only, etc.).
I suppose in your particular use case (unless you specify what type of form do you mean, where all the fields are writable) you just need to create a Catalog UI policy which will control what fields to show to the request submitter.
Regards, Ivan

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-24-2024 09:39 AM
Hello @Alan42 ,
Is there any particular reason for you to build this whole thin in the Legacy Workflow instead of Flow Designer?
As for the approach itself, you are correct, you should split the actual job into tasks, where you show only the variables that are supposed to be filled by the fulfiller of this task.
Then, using Catalog UI Policies you can control the behavior of the fields (Mandatory, Visible, Read-Only, etc.).
I suppose in your particular use case (unless you specify what type of form do you mean, where all the fields are writable) you just need to create a Catalog UI policy which will control what fields to show to the request submitter.
Regards, Ivan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-26-2024 05:17 AM
We went live in June and had an outside vendor built out our initial processes. They used workflow editor which the more I read seems like we got a bum deal. I took an existing workflow that followed a similar path to what this one required and modified a copy. Would you recommend I redo the workflow in designer?
I'm in the catalog UI policy now and this is what I was looking for. Thanks for your help.
I

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-26-2024 05:36 AM
Hi @Alan42 ,
as the official statement sounds like this:
Workflow Editor is a legacy product to maintain existing workflows already in production. For new use cases and workflows, use ServiceNow Workflow Studio. Workflow Studio is a low-code alternative to Workflow Editor. Workflow Studio is home to Flows, Processes, and many other low-code workflow solutions.
Flows are low-code alternatives to script to create a workflow that performs a succinct outcome. Flows are fully automated, often short lived, and may be used to call integrations via IntegrationHub, pause wait for record operations or a duration of time, and include complex logic to orchestrate your process.
Processes enable you to create cross-functional processes made up of multiple workflows. A Process combines multiple succinct outcomes into an end to end orchestrated process, and typically includes human and automated interactions, and is often long running over a period of time.
I'm pretty sure that you are not in danger for the nearest future if you continue with the workflow, however, if you are not that far yet, I'd consider Flow Designer.
Regards, Ivan