---
title: "ServiceNow ticket validation settings"
slug: "reference-itsm-ticket-validation-settings"
updated: 2026-11-03T14:47:51Z
published: 2026-11-03T14:47:51Z
canonical: "docs.senhasegura.io/reference-itsm-ticket-validation-settings"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.senhasegura.io/llms.txt
> Use this file to discover all available pages before exploring further.

# ServiceNow ticket validation settings

This document provides information about the ITSM ticket validation rules, which let you configure granular validation of **ServiceNow** tickets used as access justification for an access policy. More information in How to configure ServiceNow integration in Segura™.

## Path to access

1. On **Segura™ Platform**, in the navigation bar, hover over the **Products** menu and select the module you want to configure (**PAM Core**, **DSM**, or **Certificate Manager**).
2. Open the access policy you want to configure and go to its **Approvers** tab.
3. Turn on **Governance code required when justifying? *** to display the rule settings described below.

## Enable ITSM validation

| Item | Type | Required | Description |
| --- | --- | --- | --- |
| **Governance code required when justifying? *** | Toggle button | No | Enables or disables ITSM ticket validation for this access policy (default: disabled). When enabled, displays the rule configuration described in the following sections. When disabled, no ITSM validation rule is applied. |

## ITSM connection and fallback configuration

This section provides information about the ITSM connection settings and fallback behavior applied to the access policy.

| Item | Type | Description |
| --- | --- | --- |
| **ITSM connection (override)** | Dropdown menu | Defines a specific ITSM connection for this access policy. If left blank, the policy inherits the global default configuration. |
| **Fallback behavior (override)** | Radio button | Defines the policy behavior when the ITSM integration is unavailable. The options are: *Inherit from connection, Deny access when ITSM is unavailable, Allow emergency access only (break-glass),* and *Allow access and log for later audit.* |

## Accepted ticket types

Selects which **ServiceNow** ticket types are accepted as justification. At least one type must be selected.

| Item | Type | Required | Description |
| --- | --- | --- | --- |
| **Accepted ticket types** | Checkboxes (multi-select) | Yes | Options: **Incident (INC)**, **Change (CHG)**, **Problem (PRB)**, **Request (REQ)**, **Request item (RITM)**. Default: all selected. **Segura™ Platform** rejects a ticket whose prefix does not match an accepted type. |

The prefix of the informed ticket number determines the ServiceNow table queried:

| Prefix | ServiceNow table |
| --- | --- |
| INC | incident |
| CHG | change_request |
| PRB | problem |
| REQ | sc_request |
| RITM | sc_req_item |

## Rule: Ticket existence

| Item | Type | Required | Description |
| --- | --- | --- | --- |
| **Validate that the ticket exists** | Toggle button | Yes | Verifies that the ticket exists in the **ServiceNow** instance. |

## Rule: Ticket state

| Item | Type | Required | Description |
| --- | --- | --- | --- |
| **Validate ticket state** | Toggle button | No | Verifies that the ticket is in one of the allowed states. Default: enabled. |
| **Valid states** | Checkboxes, per ticket type | No | Standard **ServiceNow** states for the ticket type. See "Standard states and defaults per ticket type" for options and defaults. |
| **Custom values** | Text field, comma-separated | No | Additional state values created in the customer's **ServiceNow** instance, not covered by the standard checkboxes. One **Custom values** field is available per ticket type. Look up the technical values in the customer's ServiceNow sys_choice table for the corresponding ticket type. [NEEDS CLARIFICATION: confirm the accepted format. QA test criteria state this field rejects non-numeric entries and silently ignores whitespace/duplicates against the checkboxes, which appears to conflict with the product spec's own string-value example (`custom_awaiting_cab`). Confirm with engineering/QA which is correct before publishing.] |

Standard states and defaults per ticket type:

| Ticket type | Standard state options | Default selected |
| --- | --- | --- |
| Incident (INC) | New (1), In progress (2), On hold (3), Resolved (6), Closed (7), Canceled (8) | New (1), In progress (2), On hold (3) |
| Change (CHG) | New (-5), Assess (-4), Authorize (-3), Scheduled (-2), Implement (-1), Review (0), Closed (3), Canceled (4) | New (-5), Assess (-4), Authorize (-3), Scheduled (-2), Implement (-1), Review (0) |
| Problem (PRB) | New (101), Assess (102), Root cause analysis (103), Fix in progress (104), Resolved (106), Closed (107) | New (101), Assess (102), Root cause analysis (103), Fix in progress (104), Resolved (106) |
| Request (REQ) | requested, in_process, closed_complete, closed_incomplete | requested, in_process |
| Request item (RITM) | waiting_for_approval, request_approved, fulfillment, delivery, completed | waiting_for_approval, request_approved, fulfillment, delivery |

These are the defaults when the rule is first enabled; adjust them to match the ticket states your access policies actually require.

Info

Custom values only add entries to the ticket's existing state field. **Segura™ Platform** does not create new fields. For example, if **Custom values** is set to -6, 5 for Change in addition to the checkboxes **Scheduled (-2)** and **Implement (-1)**, the rule accepts tickets with state -2, -1, -6, or 5.

## Rule: Approval

| Item | Type | Required | Description |
| --- | --- | --- | --- |
| **Validate approval** | Toggle button | No | Verifies that the ticket is approved in **ServiceNow.** Default: disabled. |
| **Verification level** | Dropdown menu | No | Options: **Ticket approval field** (checks only the ticket's own approval field for `approved`) or **All approvers** (queries sysapproval_approver and fails if any approver record still has `state=requested`). Default: **Ticket approval field**. |

## Rule: Requester match

| Item | Type | Required | Description |
| --- | --- | --- | --- |
| **Validate requester** | Toggle button | No | Verifies that the **Segura™ Platform** user matches a user field on the ticket.Default: disabled. |
| **Match field** | Dropdown menu | No | Options: `caller_id` (who opened the Incident), `requested_for` (who the Service request is for), `assigned_to` (who the ticket is assigned to), `opened_by` (who created the record). Default: `caller_id`. |
| **Match method** | Dropdown menu | No | Options: **Email** (compares the **Segura™ Platform** user's email against the selected field via dot-walking, {field}.email) or **Username**. Default: **Email**. |

## Rule: Priority/urgency

| Item | Type | Required | Description |
| --- | --- | --- | --- |
| **Validate priority** | Toggle button | No | Restricts access to tickets at or above a priority/urgency threshold.Default: disabled. |
| **Field** | Dropdown menu | No | Options: priority (1–5) or urgency (1–3). Default: priority. |
| **Maximum accepted value** | Number field | No | The ticket's value must be less than or equal to this number. 1 is the most critical. Default: 3. |

## Rule: Assignment group

| Item | Type | Required | Description |
| --- | --- | --- | --- |
| **Validate assignment group** | Toggle button | No | Verifies that the ticket is assigned to one of the accepted **ServiceNow** groups.Default: disabled. |
| **Accepted groups** | Text field, comma-separated | No | Group names as they appear in the ticket's `assignment_group.name` field. Example: PAM Operations, Security Team. |

## Justification message

| Item | Type | Required | Description |
| --- | --- | --- | --- |
| **Require justification in addition to ticket** | Toggle button | No | When enabled, the user must also fill in a free-text justification field, in addition to the ticket number.Default: disabled. |
| **Minimum justification (characters)** | Number field | No | Minimum length of the justification text. Default: 10. |

## Validation execution behavior

When a user submits a ticket, **Segura™ Platform** identifies the ticket type by its prefix and queries the corresponding **ServiceNow** table. It then runs every enabled rule against the response and does not stop at the first failure. If one or more rules fail, all the failures are shown together as an inline message on the request form (no redirect), so the user can fix everything before resubmitting instead of discovering one problem at a time.

If a field a rule depends on comes back empty from **ServiceNow** (for example, `assignment_group`, `approval`, or `caller_id.email`), that rule fails with a message stating the field is not populated on the ticket.

## Fallback when ServiceNow is unavailable

There is no fail-open option: if the **ServiceNow** connection is unreachable (timeout, network error, API outage, or expired connector credentials), no privileged access is granted without ITSM validation. **Segura™ Platform** applies the fallback behavior configured on the ITSM connection used by this access policy: deny access, allow with emergency access, or allow with logging.

## Where to check validation results

Every validation attempt is recorded in the audit log at **Settings > Integrations > ITSM > Validation logs**: approved, rejected, and fallback-resolved attempts alike. Each record includes the ticket type, the individual result of each rule that ran, the final outcome, and (for rejections) the values found versus expected.

## Where this rule engine applies

The same validation engine applies across these modules; only the applicable access policy changes:

| Module | Where the rule engine applies |
| --- | --- |
| PAM Core | Credential checkout, session start, access request |
| DSM | Secret checkout via A2A, when governance is enabled |
| Certificate Manager | Certificate issuance/renewal request |

## Related topics

- [How to configure ServiceNow integration in Segura™](/v4-2/docs/how-to-configure-servicenow-integration-in-senhasegura)
- [Access policies registration](/v4-2/docs/pam-session-access-policies-registration)