{"revision":"c10276e953456835cdbb1f3a60d58ae1980be353","document":{"id":19884,"path":"impact/exception-reason-properties.md","title":"Configure exception reason properties","bundle":null,"doc_type":null,"release":"australia","body":"\n# Configure exception reason properties\n\nWhen real-time enforcement, `enforce_real_time_validation` is set to `true`, Recommend level findings require an approved exception reason before the form can be saved.\n\n## Before you begin\n\nRole required: sn\\_se.scan\\_engine\\_admin, sn\\_se.scan\\_engine\\_read\\_user, sn\\_se.internal\\_rest\\_integration\n\n## Procedure\n\n1.  Select whether to **Enforce rejected exception reason validations**.\n\n    When enabled, and if an exception reason is rejected, the object linked to that reason becomes read-only. Users cannot make additional changes until either:\n\n    -   The Recommend level message is resolved.\n    -   A new exception reason is submitted.\n    This ensures strict compliance with validation rules and prevents inconsistent or unauthorized updates while an exception is unresolved.\n\n2.  Select whether to **Enable approvals in production**.\n\n    If `enable_exception_reason_approvals_in_production` is set to `false`, exceptions can only be approved in the instances in which they are raised.\n\n    **Note:** This setting is only applicable to development instances.\n\n3.  Approval groups will approve or reject exception requests and receive notifications.\n\n    -   Use the`Enable approvals in production` setting to control whether exceptions can be approved in production instances or only in development environments.\n    -   Approval group\\(s\\) displays the group or groups that will approve or reject exception reasons and also receive notifications when new approvals are requested.\n4.  Select whether to **Exclude approved exception reasons from technical debt**.\n\n    When enabled, findings with approved exception reasons will be excluded from technical debt metrics.\n\n    **Note:** This does not remove the finding from the system.\n\n5.  **Upon new finding found**, `er_finding_number_validation` , determines how exception reasons are handled when the same issue is detected again in a subsequent scan.\n\n    Options are: **Auto Accept Existing Reason** and **Re-approve Existing Reason**.\n\n6.  **Upon line number change**, `exception_reason_validation`\n\n    -   ``Determines how approved exception reasons are handled when the finding's line number changes in the code.\n    -   Options are **Auto Accept Existing Reason** \\(default\\) and **Re-approve Existing Reason**.\n    Choose whether to automatically accept the existing reason.\n\n    **Note:** When you deactivate Scan Engine definitions, the system handles base system and custom definitions differently to ensure accurate entitlement tracking and prevent quota overages.\n\n<table id=\"table_deactivation_behavior\"><thead><tr><th>\n\nScenario\n\n</th><th>\n\nBehavior\n\n</th></tr></thead><tbody><tr><td>\n\nDirect deactivation of base system definition\n\n</td><td>\n\n-   The definition is deactivated via UI or API without creating an override record.\n-   No override is recorded in the system.\n\n\n</td></tr><tr><td>\n\nQuota impact check after deactivation\n\n</td><td>\n\n-   Deactivated base system definitions are excluded from active definition counts.\n-   They do not count toward custom definition quotas.\n-   System recalculates entitlements accurately when definitions change status.\n\n\n</td></tr><tr><td>\n\nOverride-then-deactivate existing workflow\n\n</td><td>\n\n-   When a base system definition is overridden and then deactivated, the behavior remains unchanged.\n-   The deactivated override does not count as a custom definition.\n\n\n</td></tr><tr><td>\n\nEntitlement hashing integrity\n\n</td><td>\n\n-   All combinations of base system and overridden definitions in active or inactive states produce consistent entitlement hash results.\n-   No regressions occur for states that existed before this feature was introduced.\n\n\n</td></tr></tbody>\n</table>    **Note:** Deactivating a definition does not remove it from the system. It only changes the active status. If you need to completely remove a definition, contact your system administrator.\n\n\n-   **[Configure exception approval behavior](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/impact/configure-exception-reasons-scan-engine.md)**  \nConfigure how exception reasons are enforced, approved, and re-evaluated when findings are detected using the ServiceNow Scan Engine.\n\n**Parent Topic:**[Configure Scan Engine parameters](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/impact/configure-scan-engine-properties.md)\n\n"}}