Allowed client errors

  • Release version: Zurich
  • Updated July 31, 2025
  • 2 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 Allowed client errors

    The Allowed Client Errors feature in the Automated Test Framework (ATF) enables ServiceNow customers to add specific known client-side JavaScript errors to an allowed list. This allows tests and steps to continue running without failing when these errors occur, helping maintain test continuity and focus on critical issues.

    Show full answer Show less

    Key Features

    • Allow Known Client Errors: Add client errors to the allowed errors list to prevent test failures caused by recognized non-critical errors.
    • Report Levels: Control how the system reports these errors in future tests with two options:
      • Warning: Tests report success but log the error as a warning.
      • Ignored: Tests report success and log the error as ignored, effectively hiding it.
    • Flexible Matching: The framework uses a contains search to match error messages, enabling broad or partial matches rather than exact strings.
    • Dynamic Updates: Changes to allowed client errors are automatically applied to the Client Test Runner without manual intervention.

    Practical Use Cases

    • Timing Constraints: Temporarily allow errors while awaiting developer fixes, such as on legacy forms with known bugs.
    • Legacy Library Issues: Ignore errors from old libraries that are unfixable or not impactful to operations.
    • Test Design Time: Allow errors temporarily during test development phases when UI changes introduce errors.
    • Platform Bugs: Permit errors linked to confirmed platform issues while awaiting patches, after verifying they are not customization errors.

    Managing Client Errors

    When client errors occur during tests, the framework initially fails the test step. Customers can then:

    • Allow client errors directly from test results, step results, or test logs review.
    • Manually add allowed client error records as needed to the Allowed Client Errors table.

    Important: Allowing client errors keeps tests running but does not guarantee test success. It is recommended to investigate all client errors to ensure there are no underlying business process issues.

    Add known client errors to the allowed client errors list to allow tests and steps to continue running when a specific error occurs. Set the report level to specify what the Automated Test Framework does when the error occurs in future tests.

    Scenarios for allowing client errors

    Test designers and developers typically allow client-side JavaScript errors to prevent certain types of known failures from impacting test design and results. Scenarios to allow client errors include:

    Timing constraints
    Temporarily allow a client error until your developers have time to investigate and resolve the issue. For example, when testing an old form containing a longstanding bug.
    Minimizing the impact of old libraries
    Ignore client errors that cannot be fixed or are unimportant to your operations to eliminate their impact on future test runs. For example, when you find a bug in an old library.
    Test design time
    Temporarily allow client errors until you finish writing tests and have time to investigate the error. For example, one of your developers modifies a UI policy and the change generates an error.
    Possible platform bug
    Temporarily allow client errors until a fix is available. Prior to reporting a platform bug to ServiceNow Technical Support, investigate the error, verify it is not a customization error, and identify the type of platform bug involved. For example, a UI policy generates an error during a test. Your investigation verifies that the issue is not a customization error and identifies a platform issue with the UI policy.
    Note:
    While adding client errors to the allowed client errors list allows the test framework to continue testing, it does not guarantee that your tests pass. Test designers and developers should always investigate client errors to determine if there are issues with your business process. For more details, see Identify and resolve client errors.

    Report levels for allowed client errors

    The report level indicates whether the test framework reports future occurrences of the error as a warning or ignores them altogether. You can change the report level of an allowed error at any time. For example, if you originally add an error as a warning, you can later change the report level to ignored.

    Report level Description
    Warning Test steps containing the allowed client error report a status of Success with warning(s). The error message appears in the test result output, and is recorded in the test logs with the status Warning.
    Ignored Test steps containing the allowed client error report a status of Success. The error is recorded in the test logs with an Ignored status.

    Matching process

    The Automated Test Framework identifies allowed client errors using a contains search rather than an exact string match. A match occurs when a client error contains a message from an Allowed Client Error [sys_atf_whitelist] record. For example, if you create an Allowed Client Error record for the error message "Test message" with a report level of Ignored, then any client error containing this string is ignored.
    Note:
    When you create or modify an Allowed Client Error record, the Client Test Runner automatically gets the update.

    Identifying and resolving client errors

    When client errors occur, the Automated Test Framework fails the test on the step that was executing when the error occurred.