Developers ยป Exception Handling Settings


Exception Handling 

Quick Links

Exception handling scripts are used to catch exceptions from other scripts, enabling you to manage and correct the resulting exceptions. They execute as asynchronous tasks, which means they run simultaneously with the original script. 

In this section, we explain how you can configure your scripts to support the Exception Handling mechanism that gathers important information which is later used to create cases in the Exception Handler workflow.

You can handle exceptions through script execution using the:

  • Exception Handling script type.
  • Exception Handler case type that is added to all tenants by default.

The following describes the general exception handling process: 

  1. You can create an Asynchronous Task script type that performs a complex and time-consuming task. Within the script, you can call the Exception Handling script when an exception occurs.
  2. When the Exception Handling script executes, it creates an Exception Handler case where you can view details about the exception.
  3. In the Exception Handler case, you can address the situation that caused the exception, and send notifications that an error occurred.
  4. The Exception Handler case type provides the following actions: 
  • Retry
  • Continue - Skip
  • Mark as Failed

The above actions have scripts attached and they exist in all tenants by default. Each script calls a corresponding implemented script that performs the task. You need to customize these implemented scripts with custom code for its particular purpose.

Note: If you make an update/change to an Exception Handling setting, make sure to 'Save' it before navigating to another page, failing which a warning message will pop-up.

To access the Exception Handling workspace, where you can manage your default settings, go to Setup > Development > Exception Handling Settings

Table of Exception Handling Settings

[Back to top]

When you open the Exception Handling Settings workspace, we display a table with the default exception handling parameters and their associated system IDs. In this table, you can replace the default system ID with a system ID for a custom item you define. 

The following table displays the default settings that delivered with your tenant:

ParameterSystem ID
Case Type's System ID
Exception Narrative (Custom Field's System ID)
Case which caused the exception (Custom Field's System ID)
User who caused the exception (Custom Field's System ID)
Script which caused the exception (Custom Field's System ID)
Action which caused the exception (Custom Field's System ID)
Edit link of the Action which caused the exception
Objects which caused the exception (Custom Field's System ID)
Exception Key (Custom Field's System ID)
Exception Message (Custom Field's System ID)
Exception description (Custom Field's System ID)
Exception Stacktrace (Custom Field's System ID)
Exception Severity (Custom Field's System ID)
Exceptions Container (Custom Field's System ID)
Script for retrying (Custom Field's System ID)
Default script for retrying
Script for ignoring the exceptions (Custom Field's System ID)
Default script for ignoring the exceptions
Script for marking the global process as failed(Custom Field's System ID)
Default script for marking the global process as failed
Assignment Group's System ID
Priority's System ID

Project's System ID

When the Priority's System ID parameter is blank, as in the table above, we assign the default priority that you configure on the workflow. You can set the default priority for all cases in the Setup > Fields & Forms > Priority Field, where you can also access the system ID for the fields. If desired, you can enter the system ID for the desired default priority in the Priority's System ID field in the table. 

Related Articles