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?

[Allen Andreas]

Hi,

Can you give more information as to how long "take a long time" actually means, just to help paint a better picture. Especially if there's concern around performance and this being a public forum, we'd like to make sure as much detail is there as this could be a "you" issue or could be a "ServiceNow" issue.

So let's detail the three flows, like:

• Flow A (Powershell only) - 15 seconds
• Flow B (Lengthy Mutliple Rest Calls) - 35 seconds!
• Flow C (etc.) - 10 seconds.

And see what we can do to help?

Thanks!

Please mark reply as Helpful, if applicable. Thanks!

[ncp]

Thanks Allen, here are the details

Scope - Global for all

Flow A - 1 Powershell activity and Catalog tasks, updated RITM

Total steps - 32 

Time taken to submit catalog item - 25 seconds

Issue - The submit button greys out and then is available again and users keep clicking submit and create multiple RITM (could be our portal issue - I didnt build the portal part)

Flow B - 2 Powershell activities (runs based on the catalog item variable selected), catalog tasks, 1 subflow (50 steps, this is multiple if loops, only one of the if loops works depending on catalog item variable selected - contains catalog task creation and checking the catalog task is closed cancelled)

Main flow steps - 46, contains catalog tasks depending on variable selected

Time taken to submit catalog item - 27 seconds

Flow C - MUltiple REST Calls and multiple actions, email notifications, for loops etc

Total steps - 94, no subflow - this grew organically and initially was a small FD that grew bigger 

Time taken to submit catalog item - 48 seconds

I have tried making this synchronous, instead of run in the background and that didnt help

I tried creating in a separate scope and that didnt seem to help, but added additional challenges

I tried adding a 3 second delay at the beginning of the flow

The workflow version of these submits in less than 10 seconds

What I'd like to know how this actually works architecturally. Does it put this in the ecc queue and wait for the queue to be processed which it probably does, because a RITM has to be created first. Does the size of the flow matter? If there are subflows do they also have to load?

Thanks for any help you can provide as this creating a headache in our environment

[ncp]

@Allen A Any thoughts on the data for the FD slow response?

[Michael Fry1]

94 steps and no subflows!? So you modified the default settings and now it's taking longer than you'd like? BTW - 48 seconds isn't bad at all unless you're trying to test it. FLOWs are better for the system than workflows despite not being instant like a workflow.

Personally, sounds like some opportunities to make subflows and insure your Actions are as clean as possible, codewise.