Connect storageguard to ServiceNow

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

StorageGuard can open ServiceNow incidents or problems for the findings it raises and keep them in step as findings are updated and closed. This article gets the connector working with the minimum settings: connect to your instance, pick the table, choose which findings go across, set a default category and assignment group, and send a first ticket. Everything else, from routing by label to CI linking and ticket templates, is optional and covered in the follow-on article.

Before you begin

Create the connector

1. Go to Settings > Interfaces > ITSM systems, click + and select ServiceNow.
2. Enter a Name, for example ServiceNow production.
3. Leave Enabled clear for now.

Connect to your instance

1. Under Connection & Authentication, enter the Host, the service account's Username and Password, and keep Port 443 and Protocol https.
2. If the StorageGuard server reaches the internet through a proxy, select Connect via proxy under Proxy Configuration.
3. Under ServiceNow Task, set Table name to incident or problem.

Choose which findings are sent

1. Under Risk filters, add a filter so only the findings you want become tickets. Start with severity Critical and High; widen later.
2. Under Risk Handling, select Send open events, Send update events and Send closed events, so a ticket is created when a finding opens, updated when it changes, and closed when StorageGuard confirms the fix.
3. Leave Automatic sending mode clear until you've sent a test ticket.
4. Keep the other Risk Handling defaults (Days to fix 30, Maximum amount of tickets to open in a single run 1500).

Set a default category and assignment group

A ticket needs a category and an assignment group. Until you've built routing rules, a default for each is enough:

1. Under Category Routing, set Default category (for example Other) and, under When category not found, select Add note to risk in case of filtration and Add note to risk in case of error.
2. Under Assignment Group Routing, set Default assignment group to the group that should receive tickets, and select the same two Add note options.
3. Click Apply.

With these set, every matching finding gets a ticket, and if anything goes wrong the reason is written on the finding's Activity tab instead of the ticket silently not appearing.

Send a first ticket

1. Select Enabled and click Apply. Nothing is sent yet, because automatic sending is off.
2. Go to Baseline Configuration > Risks and double-click an open finding that matches your filters.
3. On the Activity tab, click Send to ITSM System and select the connector.
4. In ServiceNow, open the table and confirm the record: a short description starting with the risk ID, the default category and assignment group, and an urgency. The ticket number appears on the finding's Activity tab.

If the ticket is missing or wrong, see Troubleshooting below.

Turn on automatic sending

1. Back on the connector, select Automatic sending mode and click Apply.
2. After the next analysis, check the ticket count in ServiceNow against the number of open findings matching your filters.

The connector now works. When you're ready to route tickets to the right teams, link them to CIs, sync state both ways, or change what the ticket says, continue with Fine-tune the ServiceNow integration.

Troubleshooting

Symptom	Likely cause	What to do
No ticket, and the finding has an error note	ServiceNow rejected the request.	Under Debug Mode, select Enable debug mode, enter an Email address to send failures, send again, and read the failure detail.
HTTP 401	Wrong username or password, or the account is locked.	Re-enter the credentials; check the account in ServiceNow.
HTTP 403	The account can't create records in the table.	Have your ServiceNow administrator grant the role for the table (for example itil).
HTTP 400 naming a field	A value doesn't exist in ServiceNow, usually the default assignment group or category name.	Enter the name exactly as ServiceNow shows it.
Connection timeout	The server can't reach the instance.	Check Connect via proxy, port and protocol, and firewall rules from the StorageGuard server.
Far more tickets than expected	Automatic mode with wide filters.	Narrow the risk filters; lower the per-run cap during rollout.

Related articles

• Fine-tune the ServiceNow integration
• Integrating StorageGuard with Atlassian Jira
• Review and act on a configuration finding
• Send events to other systems with webhooks