# ServiceNow

Open and close change requests for each release. Open the **ServiceNow** card on the Integrations page to connect.

## Change requests

> **Beta, early access.** Flag: `servicenow`.

Creates a ServiceNow change request and moves it through its states.

```bash
bumpkit integrations connect servicenow --set instance=acme --set username=bumpkit --api-key -
bumpkit integrations connect servicenow --set instance=acme --set auth=oauth --set client_id=abc123 --api-key -
```

| Setting | Meaning |
|---------|---------|
| `instance` | `acme` or `https://acme.service-now.com` |
| `auth` | `basic` (default) or `oauth` (client credentials grant) |
| `username` | The integration user, for `basic` |
| `client_id` | The OAuth application registry entry, for `oauth` |
| `assignment_group` | Optional assignment group for new requests |
| `password` or `client_secret` | The secret (the CLI's `--api-key`) |

Change requests follow the same events as Jira. They are `normal`, or `emergency` for break-glass and hotfixes, with risk and impact from the gate (higher when the gate failed or proved a high-severity finding). Approval moves the request to scheduled, a production deploy to implement and review, a later deploy closes it as successful, and a rollback closes it as unsuccessful. Each step adds a work note with the evidence link. Requests carry `correlation_display` `Bumpkit` and a `correlation_id`.

Failed deliveries are retried automatically and listed on the ServiceNow card, where an owner can retry them. The `integrations_connect`, `integrations_deliveries_list` and `integrations_deliveries_retry` MCP tools do the same.