Fine-tune the ServiceNow integration

[ Applies to ] StorageGuard 9.2 and later  /  ServiceNow incident or problem tables  /  ITSM Systems interface

Once the ServiceNow connector is creating tickets (Connect StorageGuard to ServiceNow), the remaining settings shape where tickets go, how they're linked to your CMDB, how they stay in sync, and what they say. None of them are required; take the sections you need.

Fine-tune risk handling

The Send … events options follow the finding's lifecycle. Each analysis moves a finding through these states, and each transition fires at most one ticket event:

What happens in StorageGuard	Finding state	Ticket event
A check fails on a system for the first time	Open	Open event: the ticket is created.
The next analysis finds the issue still there	Open (verified again)	Update event, if the finding changed; otherwise nothing.
The next analysis finds the issue gone	Closed	Closed event: the ticket is resolved.
An analyst resolves the finding by hand, and a later analysis finds it still there	Reopened	Update event; or a new ticket, per Open new ticket for reopened risk that was manually resolved.
A closed issue comes back	Reopened	Update event on the old ticket, or a new ticket if the finding was closed longer than Number of days to consider closed risk as gone.
An analyst suppresses the finding	Suppressed	Closed (suppressed) event, if enabled.

The remaining Risk Handling options cover those edge cases:

Setting	What it does	When to change it
Send closed (suppressed) events	Also closes the ticket when the finding is suppressed in StorageGuard.	Turn off if your process wants suppressed findings reviewed in ServiceNow before the ticket closes.
Number of days to consider closed risk as gone	A finding closed for this many days is treated as gone; if it reappears after that, it's a new finding and a new ticket.	Raise it if scans are infrequent and you'd rather reopen the old ticket.
Open new ticket for reopened risk that was manually resolved	If someone resolved the ticket in ServiceNow but the finding comes back, open a fresh ticket instead of touching the closed one.	Keep on. Turn off only if your process reopens resolved incidents.
Days to fix	The due date set on the ticket, counted from creation.	Match your SLA for the filtered severities.
Maximum amount of tickets to open in a single run	Caps ticket creation per analysis run.	Lower it for the first automatic run; raise it for large estates.
Send ticket as attachment	Attaches the finding detail report to the ticket, in addition to the fields in the body.	Turn on if ticket readers shouldn't need StorageGuard access to see evidence.

Route by category and assignment group

Category and assignment group each use the same three-level lookup, most specific first:

1. Check to … mapping: a specific check maps to a value. Use it for the few checks a particular team owns.
2. Label to … mapping: a StorageGuard label maps to a value. The usual way to route: label findings by platform or owning team and map each label once.
3. Default …: used when nothing matches.

When … not found (and default is not set) decides what happens with no match: Filter out (task not created) skips the ticket; the Add note to risk options write the reason on the finding's Activity tab when it's filtered or when sending fails.

For assignment groups, Detect and prefer ServiceNow assignment group by affected CI looks the CI up in ServiceNow and uses its support group when it has one, ahead of the mappings. Turn it on if your CMDB maintains support groups for storage and backup systems.

Link tickets to ServiceNow CIs

Under ServiceNow Services/CIs, StorageGuard can set the ticket's cmdb_ci to the affected system and list impacted services:

• Add affected CIs sets the configuration item to the system the finding is on. Add impacted services/CIs also adds the related services.
• Default configuration item is used when the system can't be matched in the CMDB (Unknown by default).
• Configuration item mapping patterns handle CMDB names with a prefix or suffix. ${TEXT} stands for the StorageGuard system name; add a pattern such as storage_${TEXT} for each naming convention, and StorageGuard tries them in turn.
• Use first cluster node as main configuration item (instead of cluster), under Advanced Configuration, if your CMDB models nodes rather than clusters.

Keep tickets in sync

The Send … events options push changes to ServiceNow. Enable task synchronization adds the other direction: StorageGuard reads the ticket's state back, so a ticket resolved in ServiceNow is reflected on the finding.

Under ServiceNow Configuration:

• ServiceNow state mappings lists incident states by ID and name (1 New, 2 In Progress, 3 On Hold, 6 Resolved, 7 Closed, 8 Canceled). Edit it only if your instance has custom states.
• ServiceNow closed states names which states count as closed (Resolved, Closed, Canceled by default).
• Low / Medium / High urgency maps StorageGuard priority to ServiceNow urgency values (3, 2, 1 by default).

Customize what the ticket says

Request Body Fields defines the ServiceNow fields StorageGuard sets for each event, as field-template pairs. Click the info icon for the variable list; the ServiceNow-specific variables ${SNOW_CATEGORY}, ${SNOW_SUBCATEGORY}, ${SNOW_ASSIGNMENT_GROUP} and ${SNOW_CONFIGURATION_ITEM} resolve from the routing and CI settings above.

Event	Default fields	Typical change
Open event	short_description (${SHORT_PRODUCT_NAME} Risk ID: ${RISK_ID}: ${SUMMARY}), category, subcategory, assignment_group, comments (areas, description, impact, resolution), urgency, cmdb_ci	Add fields your incident form requires, such as impact, caller_id or a custom u_ field; add the finding URL to comments.
Update event	short_description, comments, urgency	Usually none.
Close event	resolved_by, state and incident_state (6), close_code, close_notes	Change the state ID or close code to match your resolution process.

Advanced settings

Most deployments never touch these. They exist for instances with customized APIs or formatting:

Setting	When to use it
Custom APIs (Open, Attach report, Update, Close task)	Your instance exposes a scripted REST API or a custom table instead of the standard table API.
Create task staging table	Tickets are created through an import-set staging table rather than directly.
Extract task SYS ID / number: JSON path and regular expression	The create response isn't the standard one; adjust $..sys_id and $..number to where your API returns them.
Message body format (create / update / close)	Your API expects a wrapper around the field JSON; the default is { %s }.
VTL manipulation (summary, description, impact, resolution, excerpt)	How finding text is formatted for ServiceNow. The default wraps multi-line text in [code] blocks with <br/> line breaks so it renders in the ticket.
Date fields format	The date format your instance expects; default MMM dd, yyyy HH:mm:ss.

Troubleshooting

Symptom	Likely cause	What to do
No ticket, and the finding has a note saying it was filtered	No category or assignment group matched and the not-found option is Filter out.	Add the missing mapping or set a default.
HTTP 400 naming assignment_group or category	A mapped value doesn't exist in ServiceNow.	Enter names exactly as ServiceNow shows them.
CI is Unknown on every ticket	CMDB names don't match StorageGuard names.	Add a configuration item mapping pattern, or try the first-cluster-node option.
Ticket text shows raw line breaks or HTML	The VTL manipulation doesn't suit your instance's field type.	Adjust the manipulation for that field, or map the text to a journal field such as comments.
Findings don't reflect tickets resolved in ServiceNow	Task synchronization is off, or the resolved state isn't in the closed-states list.	Enable synchronization and check the state mappings.

Related articles

• Connect StorageGuard to ServiceNow
• Integrating StorageGuard with Atlassian Jira
• Review and act on a configuration finding
• Set up custom check fields and labels