Share:
Developers ยป Exception Handling Settings

PREVIOUS  |  NEXT

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
exceptionHandling.caseType.systemId
EXCH
Exception Narrative (Custom Field's System ID)
exceptionHandling.cf.narrative.systemId
exception_narrative
Case which caused the exception (Custom Field's System ID)
exceptionHandling.cf.cause.case.systemid
exception_cause_case
User who caused the exception (Custom Field's System ID)
exceptionHandling.cf.cause.user.systemId
exception_cause_user
Script which caused the exception (Custom Field's System ID)
exceptionHandling.cf.cause.script.systemId
exception_cause_script
Action which caused the exception (Custom Field's System ID)
exceptionHandling.cf.cause.action.systemId
exception_cause_action
Edit link of the Action which caused the exception
exceptionHandling.cf.cause.action.editLink
exception_cause_action_edit_link
Objects which caused the exception (Custom Field's System ID)
exceptionHandling.cf.cause.objects
exception_cause_objects
Exception Key (Custom Field's System ID)
exceptionHandling.cf.key.systemId
exception_key
Exception Message (Custom Field's System ID)
exceptionHandling.cf.message.systemId
exception_message
Exception description (Custom Field's System ID)
exceptionHandling.cf.description.systemId
exception_description
Exception Stacktrace (Custom Field's System ID)
exceptionHandling.cf.stacktrace.systemId
exception_stacktrace
Exception Severity (Custom Field's System ID)
exceptionHandling.cf.severity.systemId
exception_severity
Exceptions Container (Custom Field's System ID)
exceptionHandling.cf.exceptionContainer.systemId
exception_container
Script for retrying (Custom Field's System ID)
exceptionHandling.cf.script.retry.systemId
exception_retry_script
Default script for retrying
exceptionHandling.cf.script.retry.value
eh_retry_script_impl
Script for ignoring the exceptions (Custom Field's System ID)
exceptionHandling.cf.script.skip.systemId
exception_skip_script
Default script for ignoring the exceptions
exceptionHandling.cf.script.skip.value
eh_skip_script_impl
Script for marking the global process as failed(Custom Field's System ID)
exceptionHandling.cf.script.fail.systemId
exception_fail_script
Default script for marking the global process as failed
exceptionHandling.cf.script.fail.value
eh_process_failed_script_impl
Assignment Group's System ID
exceptionHandling.assignmentGroup.systemId
exception_handling
Priority's System ID
exceptionHandling.priority.systemId

Project's System ID
exceptionHandling.project.systemId
EXCH


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