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
- 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).
- Open the access policy you want to configure and go to its Approvers tab.
- 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