Using auto-retry functionality for your failed work items in RPA Hub

  • Release version: Yokohama
  • Updated January 30, 2025
  • 7 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Using auto-retry functionality for your failed work items in RPA Hub

    The auto-retry functionality in RPA Hub allows ServiceNow customers to automatically retry failed work items within their RPA work queues. This feature focuses exclusively on work items that fail due toApplication exceptions, enabling efficient handling of retries based on configurable parameters. It improves automation reliability by reducing manual intervention for retrying failed items.

    Show full answer Show less

    Key Features

    • Exception Type-based Retries: Auto-retry triggers only for work items marked with the Exception Type set to Application. Items marked as Business exceptions are not eligible for auto-retry.
    • Configurable Retry Limits: The number of retry attempts is controlled via the Maximum Attempts field on the Queue form, and retries occur only if the current attempt count is below this maximum.
    • Attempt Delay: Customers can specify a delay interval (in minutes) before retrying a failed work item, configured in the Attempt Delay (mins) field on the Queue form.
    • System Property Control: The maximum allowable retries are governed by the snrpafdn.queue.maximumattemptsmaxvalue system property, ensuring governance over retry limits.
    • Work Item Fields: The Exception Type and Attempts Count fields on the Work Item form track the failure reason and number of retry attempts, respectively.

    How Auto-Retry Works

    The retry process varies based on the work item’s status and exception type:

    • In Progress Status:
      • If the Exception Type is Application and attempts are under the maximum, the Attempts Count increments, status remains In progress, and the item is retried after the configured delay.
      • If max attempts are reached, status updates to Failed, and retries stop.
      • For Business exceptions, the item immediately fails with no retries.
      • If Exception Type is empty, the item stays In progress without incrementing attempts.
    • Success Status:
      • Any increment in Attempts Count clears the Exception Type and retains Success status, disabling further retries.
    • Failed Status:
      • Application exceptions with attempts below maximum revert status to In progress for retry after delay.
      • Upon reaching max attempts or for Business exceptions, status remains Failed and no retry occurs.
      • If Exception Type is empty, item stays Failed without retry.

    Important Considerations

    • The Deferred Till field, set by the system, takes precedence over the Attempt Delay and controls when the retry occurs.
    • Attempts Count is incremented only when the work item’s ReleaseMode is release, ensuring retries do not interfere with ongoing processing.

    Practical Benefits for ServiceNow Customers

    This functionality helps customers to automate the recovery of failed RPA tasks caused by application errors without manual oversight, improving process resilience and throughput. By configuring retry limits and delays, customers can tailor retry behavior to balance efficiency with system load and error patterns. Monitoring Attempts Count and Exception Types provides clear visibility into work item processing states.

    You can use auto-retry functionality in RPA Hub to retry the failed items automatically in your work queue. The retry functionality is based on the Application exception type only.

    Auto-retry overview

    Usually, in an existing Robotic Process Automation (RPA) work queue, the items are processed by the criteria that you specified. The items in this type of work queue are picked by the robots for execution.

    Let's consider a scenario where the first item in your work queue is processed successfully, and the status is updated to success. But, when the robot picks the second item in the work queue for execution, it isn't processed successfully and the status is updated to failure.

    By using auto-retry functionality instead in this scenario, the work items are retried automatically based on the value in the Exception Type field on the Work Item form, and based on the values that you enter in the Maximum Attempts field and the Attempt Delay field on the Queue form.

    There are two exception types: application and business.

    In the Work Item form, if the value of the Exception Type field is Application, the value of the Maximum Attempts field is greater than 1, and the current value in the Attempts Count field is less than the value in the Maximum Attempts field, the failed item in the work queue is automatically retried.

    Note:
    If the value in the Exception Type field is Business, the auto-retry functionality isn’t enabled.

    Queue fields and system property configuration

    To enable auto-retry functionality, you must define the values in the sn_rpa_fdn.queue.maximum_attempts_max_value system property. For more information about these values, see Configure RPA Hub properties.

    You can enable auto-retry functionality by configuring the following fields on the Queue form:
    • Maximum Attempts
    • Attempt Delay (mins)
    In the Maximum Attempts field, you define the number of attempts for the failed work items. In the Attempt Delay (mins), you define the maximum delay, in minutes, before the work item is attempted again. For more information about these fields, see Queue form in RPA Hub and Create a queue in RPA Hub.
    You can view the following fields that are related to the auto-retry functionality on the Work Item form:
    • Exception Type
    • Attempts Count
    Based on the value in the Exception Type field, the auto retry functionality retries the work items. In the Attempts Count field, you can view the number of times the work item is picked for auto retry. For more information about these fields, see Work item form in RPA Hub.

    Auto-retry workflow

    When the status of the work item that is selected in the automation is In progress, the auto-retry workflow is as follows:
    • If the Exception Type field is Application, the Attempts Count field is incremented by 1, and the current value in the Attempts Count field is equal to the value in the Maximum Attempts field, the status of the work item is updated to Failed and the Exception Type field is updated to Application. The work item isn’t available for auto-retry.
    • If the Exception Type field is Application, the Attempts Count field is incremented by 1, and the current value in the Attempts Count field is less than the value in the Maximum Attempts field, the status of the work item is updated to In progress and the Exception Type is updated to Application. The work item is available for auto-retry only after you set the duration (if any) in minutes in the Attempts Count field.
    • If the Exception Type field is Business and the Attempts Count field is incremented by 1, the status of the work item is updated to Failed, and the Exception Type field is updated to Business. The work item isn’t available for auto-retry.
    • When there’s no value in the Exception Type field and the Attempts Count field isn’t incremented by 1, the status of the work item is updated to In progress. The Exception Type isn’t updated. The work item is available for auto-retry only after you set the duration (if any) in minutes in the Attempts Count field.
    Note:
    If the value in the ReleaseMode field is locked, then you can't increment the value in the Attempts Count field because the robot is still executing the work item. The value in the Attempts Count field must be incremented only when the value in the ReleaseMode field is release. The value in the Attempts Count field is incremented when an item is released by the robot or when an item's status is set to Failure.
    The following table shows the auto-retry workflow for an In progress work item.
    Table 1. Auto-retry workflow for an In progress work item
    Exception Type Attempts Count (Increment by 1) Condition Status updated to Exception Type updated to
    Application Yes If the current value in the Attempts Count field is equal to the value in the Maximum Attempts field. Failed Application
    Application Yes If the current value in the Attempts Count field is less than the value in the Maximum Attempts field. In progress Application
    Business Yes <No condition> Failed Business
    <empty> No <No condition> In progress <No update>
    When the status of a work item that is selected in the automation is Success, the auto-retry workflow is as follows:
    • If the Exception Type field is Application and the Attempts Count field is incremented by 1, the status of the work item is updated to Success and the Exception Type is updated to blank. The work item isn’t available for auto-retry.
    • If the Exception Type field is Business and the Attempts Count field is incremented by 1, the status of the work item is updated to Success. The Exception Type is updated to blank, and the work item isn’t available for auto-retry.
    • If there’s no value in the Exception Type field and the Attempts Count field is incremented by 1, the status of the work item is updated to Success. The Exception Type field is updated to blank, and the work item isn’t available for auto-retry.
    The following table shows the auto-retry workflow for a Success work item.
    Table 2. Auto-retry workflow for a Success work item
    Exception Type Attempts Count (Increment by 1) Status updated to Exception Type updated to
    Application Yes Success <blank>
    Business Yes Success <blank>
    <blank> Yes Success <blank>
    When the status of work item that is selected in the automation is Failed, the auto-retry workflow is as follows:
    • If the Exception Type is Application, the Attempts Count field is incremented by 1, and the current value in the Attempts Count field is less than the value in the Maximum Attempts field, the status of the work item is updated to In progress. The Exception Type field is updated to Application, and the work item is available for auto-retry only after the duration that you set in the Attempts Count field.
    • If the Exception Type field is Application, the Attempts Count field is increment by 1, and the current value in the Attempts Count field is equal to the value in the Maximum Attempts field, the status of the work item is updated to Failed. The Exception Type field is updated to Application, and the work item isn’t available for auto-retry.
    • If the Exception Type is Business, the Attempts Count field is incremented by 1, the status of the work item is updated to Failed. The Exception Type field is updated to Business, and the work item isn’t available for auto-retry.
    • If there’s no Exception Type field and the Attempts Count field is incremented by 1, the status of the work item is updated as Failed. The Exception Type field isn’t updated, and the work item isn’t available for auto-retry.
    The following table shows the auto-retry workflow when the Failed status is selected in the automation.
    Table 3. Auto-retry workflow for a Failed work item
    Exception Type Attempts Count (Increment by 1) Condition Status updated to Exception Type updated to
    Application Yes If the current value in the Attempts Count field is less than the value in the Maximum Attempts field. In progress Application
    Application Yes If the current value in the Attempts Count field is equal to the value in the Maximum Attempts field. Failed Application
    Business Yes <No condition> Failed Business
    <empty> Yes <No condition> Failed <No update>
    Note:
    The value in the Deferred Till field is obtained from the component. This field always takes precedence over the Attempt Delay (mins) field. The Deferred Till field is a read-only field on the work item form. For more information, see Work item form in RPA Hub.