Workflow Automation CoE > Flows > Best Practices > Action Designer Error Handling

Action Designer Error Handling

• Reference Action error evaluation.
• Author catch conditions for actions to provide meaningful user-friendly error messages as opposed to system messages.
• Enable actions to catch step failures, and gracefully continue running your flow.
• Return action status code, status message, and error state.
• Allow only independent steps to continue running.
  
  • Allow a step to continue running if it does not return data required by a later step.
    
  • If a step provides data necessary for later steps, then you know that the later steps cannot run successfully.
• You can use the Step Status to identify when a specific step fails.
  
  • Identifying a specific step can be useful when your action contains multiple instances of the same type of step.
    
  • You may also want to identify a specific step so that a flow error handler can take specific corrective actions for the failure.
• Put specific error conditions before general error conditions.
• Error evaluation stops as soon as the action finds a matching error condition.
  
  • Putting general error conditions first may prevent the action from ever matching specific error conditions.
• Use descriptive error condition labels.
  
  • By default, you can only see error condition conditions when you edit them.
    
  • A descriptive label allows you to identify an error condition without having to edit it.
• If Action input validation is required (aka, check for nulls, or check if reference pill exists), create a Pre-processing script step to perform validation.
  
  • Use gs.error to log detailed error in case of failures.
    
  • Before integration step, check for empty values in run time and throw errors.
    
  • All inputs at action level and step level should be validated against null.
• Add action error conditions for errors generated from Integration step like REST, PowerShell, or SOAP.
• Decouple platform error messages from API error messages - This will reduce cohesion and will enable flow authors to write logic based on platform error messages.
• Make error messages understandable to the Process Analyst e.g. if the error returned from active directory is "The RPC server is unavailable", it can be swapped with a more user-friendly error message as "Invalid hostname or host unreachable".
  Benefit:
• The benefit of this is that if the backend API error message changes in future, Different flows that depend on this error message to take a decision need not re-publish their flows.
• If an API change occurs, the action may be updated rather than having to update every Flow with the new API message. The update can be made in a single place i.e. the script step in Action designer, and all the flows using the authored error message do not require modifications.
• Error messages should be short and self-explanatory.
• The output Error Message must be populated if Status is Error.
• Author an error handler for all Status Codes. For each of the status codes, there might be multiple error messages. Enumerate all these error messages.
• In case API doesn't give proper response, show generic error.
• Fail early. If the provided inputs are not enough to hit the target API, throw error.
• Handle API version related errors and show, if possible, the supported versions.

Center of Excellence Navigation