Open ServiceNow incidents
SZ-MCP can open a ServiceNow incident for each HARD CRITICAL problem that nobody has handled, and keep it in step. Acknowledgements and state changes add work notes, and recovery resolves the incident. Every minute, SZ-MCP compares the current problems with the incidents it has open and sends the difference. A failed step is still a difference a minute later, so it is retried. Set it up under Configure › Integrations (admins only). The rules every integration follows apply here too.
How do I set it up?
Section titled “How do I set it up?”- In ServiceNow, create a user with the
itilrole (or rights to create and update incidents), or an API key on Washington DC or later. - In SZ-MCP, open Configure › Integrations, click Add an integration, and choose ServiceNow (incidents).
- Enter a Name and the Instance URL (for example
https://acme.service-now.com). - Choose User and password (enter the User and Password) or API key (Washington DC or later) (enter the API key).
- Set the fields below, then click Save.
- Click Send now to check the connection. It reads one incident, and looks up the assignment group and caller if you set them. It reports, for example, “connected, incidents readable, group “Network Operations” found”.
Incidents open for new HARD problems from then on.
What do the fields do?
Section titled “What do the fields do?”| Field | Default | Effect |
|---|---|---|
| CRITICAL problems / WARNING and CRITICAL | CRITICAL problems | The lowest state that opens an incident |
| Assignment group (name or sys_id, optional) | none | Looked up by name if not a sys_id |
| Caller (user name or sys_id, optional) | none | Some instances require one |
| Category / Subcategory (optional) | none | Set on new incidents |
| Impact for CRITICAL | 2 - Medium | 1 - High, 2 - Medium or 3 - Low |
| Urgency for CRITICAL | 1 - High | 1 - High, 2 - Medium or 3 - Low |
| Resolve the incident when the problem recovers (otherwise a work note) | On | |
| Close code | Solution provided | Must be one of your instance’s close codes |
WARNING and UNKNOWN problems get impact and urgency one step lower each.
What happens to an incident over its life?
Section titled “What happens to an incident over its life?”An incident follows its problem from HARD to recovery:
- Opened when a problem is HARD, at or above the chosen state, and not handled. Handled means acknowledged, in downtime, unreachable (its upstream is down) or flapping. So an outage behind one switch opens incidents for the switch, not for every AP behind it.
- Short description
sz-mcp: <problem>. The description is the notification text, with the runbook, site notes, context and event explanation, ending with which integration opened it. - Each incident carries a correlation id derived from the organisation, rule and device. Before creating, SZ-MCP looks for an active incident with that id, so a lost record never opens a duplicate.
- Work notes are added when the problem changes state, is acknowledged or goes into downtime.
- Resolved on recovery (state 6, with your close code). With resolving off, a work note says it recovered instead.
- Closed by a person while the problem is still there? SZ-MCP stops writing to it. A new incident opens only after the problem has recovered and come back.
What limits apply?
Section titled “What limits apply?”| Limit | What happens |
|---|---|
| 10 new incidents a minute per integration | The rest open over the following minutes |
| 100 open incidents per integration | No more open until some close |
The integration’s line shows how many incidents are open and their numbers.
What errors can I get?
Section titled “What errors can I get?”| Message | What to check |
|---|---|
ServiceNow … HTTP 401 … (check the user and password or API key) | The credentials |
ServiceNow … HTTP 403 … (the user needs the itil role, or an ACL allows the incident table) | The user’s roles |
ServiceNow: no assignment group "<name>" / ServiceNow: no user "<name>" | The assignment group or caller name |
ServiceNow …: not a JSON reply (is the instance awake?) | A sleeping developer instance, or a login page in front of it |
Next steps
Section titled “Next steps” Forward logs to Splunk or syslog Alert changes, alarms and admin activity to your SIEM.
How alerts work HARD, acknowledged, downtime and unreachable: what opens an incident.
Notifications The notification text an incident's description is built from.