ServiceNow Flow Designer - Handling a complex flow

[Shantanu1]

Hi Experts!

I have a requirement to set an Application Access workflow for around 30 Applications, each application will have a separate approval criteria & separate failure/error handling.

The requirement is to use a single service catalogue to trigger a flow that can handle each application, but the Flow is getting huge & complex. What should be best way to achieve this requirement? Using sub flows is an option but I am open for more ideas.

Thanks,

Shantanu

[Bimschleger · Accepted solution]

Sounds like a great use case for the combination of 'decision table' and 'dynamic flow'. 😁

Use one flow as the primary fulfillment flow, and then dynamically run the appropriate subflow based on details from the requested item.

@Lisa Holenstein wrote up a great article on the approach. What's nice about this approach:

1. Whenever you add new applications and want to include them, you just need to update the decision table logic and create the subflow for the new application.
2. The original service catalog fulfillment flow doesn't need to be changed at all.
3. Each dynamic subflow can contain its own error handling.

[Shantanu1]

Great! Thanks for the suggestion, This will be perfect for our use case!

[Zod]

I can't agree with this. Using subflows for every application still leads to code duplication, including actions and related logic. If changes are needed across all, you'd have to update multiple subflows—hardly efficient.

Also, Flow Designer is far from intuitive: debugging complex processes is a nightmare, and tracking errors is unnecessarily cumbersome. I’ve always preferred a single, well-organized workflow, leveraging tools like the workflow scratchpad for flexibility.

The hype around Flow Designer baffles me—its visualization is mediocre at best. When dealing with numerous flows, the lack of manageability and scalability becomes a real problem.

Additionally, the decision table was a complete mess the last time I used it, causing significant issues during the transition from DEV to PROD. By design, it's intended to allow dynamic changes directly in the PROD system, which inevitably leads to mismatches between environments. This approach complicates testing in DEV and undermines consistency across instances.