---
sourceDocument: Brazil Impact
sourceDocumentLink: https://www.servicenow.com/docs/r/impact

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil Impact

ft:clusterId :

    - ipact

bundleId :

    - ipact


---

# Exception handling in Scan Engine

# Exception handling in Scan Engine {#ariaid-title1}

Release version: Brazil  
Updated October 28, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 minutes to read  
Exception handling enables developers and administrators to manage findings that are out of scope, pre-existing, or acceptable risks. The Scan Engine exception model supports enterprise approval workflows, predictable lifecycle behavior, and reliable governance across all finding levels.

## What are exception reasons {#exception-handling-overview__what_are_exceptions}

Exception reasons allow developers to request that findings be excluded from technical debt metrics and blocked workflows. When a finding is detected that an organization determines should not be considered an issue, developers can
submit an exception request with supporting rationale. After approval by designated administrators, the finding is excluded from technical debt calculations and no longer blocks form submissions.

Exception handling serves several key purposes:

* Unblock Update Set closure when findings are out of scope or represent acceptable risks
* Exclude pre-existing or non-blocking issues from technical debt metrics
* Maintain audit trails showing which findings have been reviewed and approved
* Support enterprise governance patterns where approvals follow organizational structures

## Exception reason scope {#exception-handling-overview__exception_scope_model}

Exception reason scope controls which finding levels can have exception reasons submitted and approved. Administrators configure the scope to match organizational needs. The scope options are Recommend only, which is the default, Act and Recommend, and All levels. The scope controls only which levels can have exceptions, and it doesn't decide which findings block a save. For what each option means, see [Configure exception reason properties](https://www.servicenow.com/docs/~y4ae877ZkIsjacUhwCIgw "When real-time enforcement, enforce_real_time_validation, is enabled, exception reasons can be configured for Suggest, Review, Recommend, and Act level findings based on the exception reason scope. The scope controls which finding levels can have exceptions. It doesn't decide which findings block a save.").

The exception scope you select determines the user experience in the Findings panel. When exception reasons are enabled for a finding level, developers see a Create exception button on the finding card. When
exceptions aren't enabled for a finding level, the button won't appear.

## Approval and enforcement {#exception-handling-overview__approval_and_enforcement}

After a developer submits an exception request, designated approval groups review the request and either approve or reject it. Approvers can be different from administrators who configured the exception settings. When an exception
is approved, the finding is automatically excluded from technical debt metrics. Certain settings configured by a system administrator can determine whether an exception is approved or rejected automatically.

Administrators control the approval behavior in Scan Engine Properties. They choose the approval groups, whether exceptions are approved in production, what happens to a linked object when a request is rejected, and whether
approved exceptions are re-evaluated when the same issue is found again or the line number changes. For each setting and its values, see [Configure exception reason properties](https://www.servicenow.com/docs/~y4ae877ZkIsjacUhwCIgw "When real-time enforcement, enforce_real_time_validation, is enabled, exception reasons can be configured for Suggest, Review, Recommend, and Act level findings based on the exception reason scope. The scope controls which finding levels can have exceptions. It doesn't decide which findings block a save.").

## Exception lifecycle {#exception-handling-overview__exception_lifecycle}

An exception reason moves through four states: Not Yet Requested, Requested, Approved, and Rejected.

## Finding levels and exception eligibility {#exception-handling-overview__finding_levels}

The Scan Engine classifies findings into four levels based on severity and risk. See [View scan results for Scan Engine](https://www.servicenow.com/docs/NeP4LeOh5nlKmcKWc~8rSQ "You can view scans in real-time as they run or after they're completed. ") for additional information on finding levels.
{#exception-handling-overview__finding_levels__entry__3}

| Level | Severity | Form blocking and exception behavior |
|-|-|-|
| Suggest | Low | Doesn't block form submission. Exception reasons can be submitted if the scope is set to All levels. |
| Review | Low-Medium | Doesn't block form submission. Exception reasons can be submitted if the scope is set to All levels. |
| Recommend | Medium-High | Blocks form submission when real-time enforcement is enabled, unless an exception is submitted for it. The exception can be a draft, and it doesn't need to be approved. Exception reasons can be submitted if the scope is set to Recommend only, Act and Recommend, or All levels. |
| Act | Critical | Blocks form submission when real-time enforcement is enabled, unless it is resolved, or it is eligible for an exception and has one submitted. The exception can be a draft, and it doesn't need to be approved. Exception reasons can be submitted if the scope is set to Act and Recommend or All levels. |
[Table 1. Finding levels and exception behavior]

## Common use cases {#exception-handling-overview__use_cases}

Out-of-scope findings
:   A definition triggers on utility functions or platform code that your team intentionally excludes from scanning. Rather than disabling the definition, submit exceptions for out-of-scope matches so the definition remains active for other code contexts.

Pre-existing issues
:   A finding identifies an issue that exists in legacy code. Rather than blocking Update Set closure, submit an exception with a plan to remediate in a future release.

Acceptable risks
:   A finding identifies a pattern that your team has reviewed and determined is acceptable for your use case. Submit an exception to exclude it from technical debt and avoid form blocking.

Update Set closure
:   An Update Set contains a finding at Act level that prevents closure. Developers submit an exception explaining why the change is necessary. Approvers review and approve, allowing the Update Set to proceed.

## Roles and permissions {#exception-handling-overview__roles_and_permissions}

Exception handling requires specific roles and permissions. Developers can submit exceptions when they have developer roles. Administrators configure exception settings when they have admin or Scan Engine admin roles. Approvers are users in an approval group or users who hold the Scan Engine exception approver role, sn_se.scan_engine_exception_approver.

See [Roles installed with Impact](https://www.servicenow.com/docs/lhj2SK8DnaL4of6LNgXD3Q "Impact offers many roles to assign to fit your business needs. When you log in to Impact, you’ll see a personalized view of your objectives, metrics, and recommendations tied directly to your role.") for detailed role descriptions, including roles that manage exception approvals.

## Related tasks {#exception-handling-overview__related_tasks}

To implement exception handling in your organization, see:

* [Configure exception approval behavior](https://www.servicenow.com/docs/v0CQV5i_PWo7Mitc2ymn4w "Configure how exception reasons are enforced, approved, and re-evaluated when findings are detected using the Scan Engine. Settings control exception behavior."): Set the exception reason options in order.
* [Submit exceptions for Scan Engine findings](https://www.servicenow.com/docs/F7Booolb~qDPKOdLNOSi3g "Developers can submit exception requests for Suggest, Review, Recommend, and Act level findings if they determine the finding should not be considered an issue to deter development. The availability of each finding level depends on the exception reason scope configured by your system administrator."): Submit exception requests for findings that your team has reviewed.
* [Configure exception reason properties](https://www.servicenow.com/docs/~y4ae877ZkIsjacUhwCIgw "When real-time enforcement, enforce_real_time_validation, is enabled, exception reasons can be configured for Suggest, Review, Recommend, and Act level findings based on the exception reason scope. The scope controls which finding levels can have exceptions. It doesn't decide which findings block a save."): Reference for each exception reason setting and its values.

