Exception handling in Scan Engine
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 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 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.
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
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.
Exception lifecycle
[Omitted image "exception-lifecycle.png"] Alt text: The developer lifecycle for submitting an exception.
An exception reason moves through four states: Not Yet Requested, Requested, Approved, and Rejected.
Finding levels and exception eligibility
The Scan Engine classifies findings into four levels based on severity and risk. See View scan results for Scan Engine for additional information on finding levels.
| 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. |
Common 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 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 for detailed role descriptions, including roles that manage exception approvals.
Related tasks
To implement exception handling in your organization, see:
- Configure exception approval behavior: Set the exception reason options in order.
- Submit exceptions for Scan Engine findings: Submit exception requests for findings that your team has reviewed.
- Configure exception reason properties: Reference for each exception reason setting and its values.
---
title: Exception handling in Scan Engine
description: 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.
locale: en-US
canonical_url: https://www.servicenow.com/docs/r/australia/impact/exception-handling-overview.html
release: australia
topic_type: concept
last_updated: "2026-10-28"
reading_time_minutes: 5
keywords: [exceptions, exception reasons, exception approval, findings, governance]
breadcrumb: [Prevent technical debt with real-time code fixes, Platform Health, Using Impact, Impact]
---
# Exception handling in Scan Engine
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 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 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://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/impact/exception-reason-properties.md).
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
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://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/impact/exception-reason-properties.md).
## Exception lifecycle
\[Omitted image "exception-lifecycle.png"\] Alt text: The developer lifecycle for submitting an exception.
An exception reason moves through four states: Not Yet Requested, Requested, Approved, and Rejected.
## Finding levels and exception eligibility
The Scan Engine classifies findings into four levels based on severity and risk. See [View scan results for Scan Engine](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/impact/viewing-scan-results-scan-engine.md) for additional information on finding levels.
|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.|
## Common 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 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://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/impact/impact-roles.md) for detailed role descriptions, including roles that manage exception approvals.
## Related tasks
To implement exception handling in your organization, see:
- [Configure exception approval behavior](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/impact/configure-exception-reasons-scan-engine.md): Set the exception reason options in order.
- [Submit exceptions for Scan Engine findings](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/impact/submitting-exception-reasons-scan-engine.md): Submit exception requests for findings that your team has reviewed.
- [Configure exception reason properties](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/impact/exception-reason-properties.md): Reference for each exception reason setting and its values.
| title | Exception handling in Scan Engine |
| description | 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. |
| locale | en-US |
| canonical_url | https://www.servicenow.com/docs/r/australia/impact/exception-handling-overview.html |
| release | australia |
| topic_type | concept |
| last_updated | 2026-10-28 |
| reading_time_minutes | 5 |
| keywords | exceptionsexception reasonsexception approvalfindingsgovernance |
| breadcrumb | Prevent technical debt with real-time code fixesPlatform HealthUsing ImpactImpact |