Flows Best Practices Error Handling - Workflow Automation CoE

[Lisa Holenstein]

Workflow Automation CoE > Flows > Best Practices > Error Handling and Debugging

Flows Best Practices Error Handling

For a detailed introduction into Error Handling, check out this article series and workflow academy video.

• Provide try/catch or flow catch logic to Flows to ensure graceful recovery of error.
  • Your Flow can now include conditional logic based on action errors. You can either add an If logic on Action > Action Status > Code | Error Message, leverage the Flow Error Handler, or the Try Flow Logic, to create graceful handling of errors when they occur, including attempting to retry, pausing for input, etc.
  • Reference Flow Error Handler
  • Reference Action error evaluation
• Identify flow errors as they happen.
  • Capture and push flow error information (e.g., notify process owner).
  • Create a report or dashboard showing the state of your process.
  • The Error Status object contains information about the action that produced an error. You can use this information to identify the cause of the error as well as record data that may need correction.
• Automate the resolution of flow errors.
  • Run actions and subflows to remediate the error when possible.
  • Optionally create a task for the process owner to take action for remediation or recovery.
• Author flows to never fail.
  • Suppress action and subflow error messages.
  • You can enable the Error Handler for a subflow to prevent its errors from cascading to a parent flow. Leaving the subflow Error Handler section empty ensures that it always generates the Completed (error caught) state.
• Avoid adding error handling items to the main section of the flow.
  • A flow normally stops running when an action or subflow returns an error in the main section.
  • A stopped flow cannot run any actions or subflows past the point where it returned an error.
  • Adding error handling actions and subflows to the Error Handler section ensures the error response occurs when there is an error.
• 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.

When things go wrong

• Review the logs in the related list on the sys_flow_context record.
• Logs from elsewhere in the platform are controlled by com.glide.hub.flow_engine.listener_trace.threshold (default: ERROR).
• Set it to WARN or INFO temporarily while troubleshooting and then reverting it back.
• Enable flow reporting on a per flow basis temporarily.

Center of Excellence Navigation

1. Workflow Automation - Center of Excellence
2. Workflow Automation Migration Considerations
3. What's new for Workflow Automation?
4. Resource Hubs
   1. Flows
   2. Decision Tables
   3. Playbooks
5. FAQ
6. Training
7. Workflow Academy

[GoBucks]

Is there a good resource that compares the Flow Error Handler to the Try Flow logic? (ie, when to use one or the other, etc.)

[Lisa Holenstein]

Hi @GoBucks!

The Flow Error handler is there to execute a couple of flow actions or logic, whenever you have set them up and any step in the flow runs into an error. The remaining flow will be canceled and the steps in the error handling section are being executed.

Try Flow logic is designed to catch a potential error, but let the following flow proceed. Without it, as soon as one step in your flow runs into an error, the rest of the flow will be canceled. With Try, it'll try to execute a specific action (or several actions or a subflow). If it runs into an error, it'll be specified as 'caught', run the error section of the try logic, and then the rest of the flow will proceed as if no error happened.

This is specifically useful if you're calling an API or trying to send an SMS and default back to an email notification in case of a delivery error.

[GoBucks]

@Lisa HolensteinThanks for the feedback.  Since a Flow can technically have both Try logic and the Error Handler turned on with its own set of logic to follow, I was wondering what exactly occurs when both exist on a Flow and an error is encountered. Does the Flow stop, try to continue, or what exactly?

[Lisa Holenstein]

If an error is caught within the Try logic, it counts as "Completed (Error caught)" and does not trigger the error handler section. Other errors outside of it will have the rest of the flow execution to be canceled and then jump to the error handling.