Flow Designer service catalog very slow

[ncp]

I have moved 3 of my workflows into Flow Designer. One of them is lengthy and complicated and two of them are smaller, ie depending on a certain request type I create catalog task or some I automate using a Powershell script. The larger one has multiple REST calls etc. 

On submission all the flows take a long time to submit the catalog item and the larger one takes extremely long. I tried moving it to its own scope (that raises its own set of challenges with notification etc and access to certain global tables), but that didnt help. 

Since ServiceNow is pushing everyone to FD, why would there be performance issues like this and any ideas as to what can be done?

[ncp]

@Michael Fry Thank you for your response

Yes it grew organically and there were no subflows created. So my question is this - do adding subflows improve performance or does it just make it modular and easier to work with. If it improves performance, I would like to know why - ie is it because subflows are not loaded when a catalog item is submitted and only loaded during run time? I have seen workflows that are much larger that are tied to catalog items that take less than 10 seconds to submit. 

When you say I modified the default settings - not sure I followed that

I disagree that 48 seconds isnt bad, the workflow that was associated to it took 10 seconds, you cannot expect a user to click submit and wait 48 seconds.

I will work on creating subflows, but I dont want to put in all the effort to see the same result, if there is an underlying issue with how FD is architected.

[Michael Fry1]

You shouldn't be comparing the performance of workflows and flows. As we have learned, workflows aren't the best for the system. Nowadays we need to build our systems for performance, not speed only.

In the past adding subflows helps BUT I can't explain the why part. Open a HI ticket and talk to SN.

If you think about the normal flow of things, a user submits a request, the receiving group isn't waiting for the flow, honestly they probably don't even know about the ticket until the flow runs and assigns it. Once they get it and close the first task, again, is the agent waiting for the second task? Probably not in that <30 seconds it takes for the 2nd task to show.

[ncp]

This is for catalog items, so converting a workflow to FD has a huge impact to end users. What is happening is the user is hitting submit after adding the catalog item and then waiting for 48 seconds for the RITM number to come back. 

If FD is the future, then end user performance has to be taken into account. From their perspective they dont care if its workflow or FD in the backend. A catalog item has been submitted and what used to take 10 seconds to get the RITM number back is now taking 48 seconds

[ncp]

So I spent the time to create a new application scope and copied all my actions to that scope

Created multiple new subflows for the flow that had 94 steps

Now I have 57 steps

Now clicking on submit takes 35 seconds, so I saved ~10 seconds moving to its own app scope and creating subflows - not a huge improvement, especially since its a end user impact. Like Michael said, if it would submit within 10 seconds, it would not have mattered as the next steps could take as long as it wants (Creating appoval records, catalog tasks etc).

But if moving to an app scope and creating subflows just saves me 10 seconds out of 45, its not a huge improvement. If it was clear as to what it does I could ask ServiceNow to add more nodes, memory, cpu etc. 

HI time I guess 😞

[Alex248]

Hello,

We also created  Hi support case after we moved our workflows to flows. We noticed that approval actions and task creation spent much more time compare to workflows.

One of their response is:

There's PRB1404497 which deals specifically with a delay when running in foreground when the trigger type is Service Catalog. The PRB will be addressed in Paris Patch 4 which is scheduled for later this month

Paris fixes

Other possible reason can be in nodes count. Dev instance has only one, so performance should be lower.

Try to change Where to run the flow to foreground. It may help.