Can you use a sub-flow in error handler?

[Jessica Casey]

Hi All, 

We are currently working with our managed service provider to have error handler turned on for all our active catalog items (about 50).

My internal developer thought the best option would be to create a subflow called "error handler subflow" that has all the required actions we need within that subflow like this:

Then we'd insert that subflow within the error handler loop like this so there'd only be one action under it like this:

Even though we indicated in our user requirements to our Managed Service Provider that we wanted to do it as a sub-flow so if we needed to add/remove steps we can do it in the subflow and not inside each individual catalog item, they proceeded with adding 4 manual actions inside all 50 catalog items we have currently. We have near term plans to break out our catalog items which will likely double the amount we have now so we want to ensure we get this done the right way to minimize rework later. When I asked our managed service provider to clarify further as to why they took this approach, the response back was that it's ServiceNow's Best Practice. I asked for further documentation that indicates that and they provided a link to this statement within SN Docs here. 

My interpretation of this is that you can have a max of 10 steps and if you need more than 10 steps you have to use a subflow. However there is no indication that you cant use a sub-flow if there's less than 10 steps (i.e. putting the 4 steps they created into 1 subflow and then inserting that 1 subflow into all 50 catalog items instead of putting 4 steps individually into all 50 items).

What is the best route forward in your opinion? What have you see others do? What is the best practice for subflows within the error handler, if one exists?

[Soeren Maucher]

Hello @Jessica Casey, 

I would definitely agree with your internal developer and the suggeston of creating an "error handler subflow". I have just recently implemented the same in a similar scenario where we wanted to standardize error handeling across multiple flows/subflows and it works perfectly. It will definitely save you a lot of effort if the requirements for error handeling slightly change in the future, since you will only have to do one adjustment insted of 50+. 

From my point of view the statement from ServiceNow regarding max 10 steps in error handeling is even another reason to do so. In a flow for instance the maximimum number of steps is 50 and thus a common approach for complex flows is grouping logically connected steps in a subflow and creating a flow of subflows. I dont see a reason why in the error handler this should be done differently. 

Greetings,
Sören

[Soeren Maucher]

Hello @Jessica Casey 

coincidently, today I stumbled across a sentence in my notes which I copied from one of the official ServiceNow labs (unfortunately I do not remember which lab it was). In this case, ServiceNow explicitly advises to use a subflow.

“Create reusable action or subflow for handling errors.

Rather than forcing an error-handling-process to fit within a 10-item limit (enforced limit of actions within the flow catch section), call a subflows that can contain many more items, and provide a response that your error logic leverages.

Rather than recreate the same sequence of actions in multiple flows, create reusable subflows to correct errors to your record data. When a flow error leaves your record data in an undesired state, use subflows to correct these records. You can use the error handler to identify such record data as a subflow output.”

I hope this helped!

Greetings,
Sören