IT & Security package
ServiceNow sends a change for approval; CI criticality and a risk table route it, the CAB approves, rejects or asks for info, and the approval is written back.
Connects to ServiceNow
About this package
ServiceNow change approval moves CAB decisions into a focused review task while ServiceNow stays the system of record. When a change request reaches Authorize, a business rule or flow posts its sys_id to the workflow.
The workflow reads the change from the Table API (type, risk, impact, CI, window, implementation / backout / test plans and conflicts), looks the CI up in the CI criticality table and evaluates the Change risk route decision table: emergency changes go to the ECAB, standard changes are approved automatically, high-risk changes and critical CIs go to the CAB and the rest to the change manager.
It finds the pending sysapproval_approver record for the change. The reviewer gets a task with the plans, the checks for the route and Approve, Request info and Reject buttons. Approve and Reject PATCH the approval record with the comments, so the ServiceNow change model moves on by itself; Request info adds a work note to the change. The change team is emailed the decision.
Starts from ServiceNow: a business rule on change_request (state changes to Authorize) posts {"sys_id": current.sys_id} to the workflow webhook.
Another system starts it over REST or an inbound webhook. No UI is needed; people only appear where a decision needs a human.
The flow
Change sent
ServiceNow posts the change_request sys_id when it reaches Authorize.
Read the change
GET /table/change_request/{sys_id} returns type, risk, CI, window and plans with display values.
Route by risk
The CI criticality table and the Change risk route table pick ECAB, CAB, change manager or pre-approved.
Find the approval
GET /table/sysapproval_approver finds the requested approval record for the change.
CAB decides
The reviewer checks the plans and window and chooses Approve, Request info or Reject.
Write back
PATCH the approval record (approved / rejected with comments) or add a work note to the change; the change team is emailed.
Forms
The inputs a caller passes when it starts a run, and the forms people complete when the process needs a decision.
Start inputs
Passed by the calling system
User Task
{{route}}: {{number}} {{short_description}} (risk {{risk}}) · 3-column grid · own header and theme
Headless
Every workflow can be started over REST, MCP or the CLI, whatever its trigger, with the sample input below. Runs start straight away on the published version; replace <workflow id> with the id the install created.
REST
curl -X POST "$USERTASKS_URL/api/v1/workflows/start" \
-H "Authorization: Bearer $USERTASKS_API_KEY" \
-H "Content-Type: application/json" \
-d '{"workflow_id":"<workflow id>","variables":{"sys_id":"c286d61347c12200e0ef563dbb9a71df","number":"CHG0030457","notify_email":"payments-platform@example.com"}}'CLI
usertasks workflows inputs <workflow id> # the start form: keys, types, required
usertasks workflows run <workflow id> --input sys_id=c286d61347c12200e0ef563dbb9a71df --input number=CHG0030457 --input notify_email=payments-platform@example.com --waitInbound webhook
usertasks webhooks create <workflow id> # prints the hook slug and secret once
curl -X POST "$USERTASKS_URL/api/webhooks/inbound?hook=<slug>" \
-H "Authorization: Bearer <webhook secret>" -H "Content-Type: application/json" \
-d '{"sys_id":"c286d61347c12200e0ef563dbb9a71df","number":"CHG0030457","notify_email":"payments-platform@example.com"}'What's included
| Type | Name | Details |
|---|---|---|
| Email template | Change decision | Sent to the change requester's team when the CAB decides or asks for more information. |
| Data table | CI criticality | How critical each configuration item is: the workflow looks the change's CI up by name to set the risk route. Unknown CIs count as medium. |
| Integration | ServiceNow | ServiceNow Table API (/api/now). Use an OAuth bearer token (or Basic auth) for an integration user that can read change_request and update sysapproval_approver records. |
| API reference | Add change work note | PATCH /table/change_request/{{sys_id}} — Add a work note to the change request (PATCH /table/change_request/{sys_id}), e.g. the CAB's questions when more information is needed. |
| API reference | Find pending approval | GET /table/sysapproval_approver — Find the requested approval record for the change (GET /table/sysapproval_approver?sysparm_query=sysapproval={sys_id}^state=requested). |
| API reference | Get change request | GET /table/change_request/{{sys_id}} — Read the change request with display values (GET /table/change_request/{sys_id}?sysparm_display_value=all): type, risk, CI, window, plans and requester. |
| API reference | Set approval | PATCH /table/sysapproval_approver/{{approval_sys_id}} — Approve or reject the approval record (PATCH /table/sysapproval_approver/{sys_id} with state approved / rejected and comments). The change workflow in ServiceNow then moves the change on. |
| Decision table | Change risk route | 6 rules — Which approval a change needs, from its type (normal / standard / emergency), the ServiceNow risk and the criticality of the CI. First matching rule wins. |
| Workflow | ServiceNow change approval | 20 steps — ServiceNow posts a change request awaiting approval; the CI criticality and the Change risk route decide the approval, the CAB (or change manager) approves, rejects or asks for information, and the decision is written to the sysapproval_approver record. |
CI criticality · 5 sample rows
CI nameCI classCriticalityBusiness serviceSupport groupExempt from change freeze
Requirements
Credentials never travel in a package. The install wizard asks for what your environment must provide, or installs it incomplete until you finish setup.
Integration “ServiceNow”Required
Workflow “ServiceNow change approval” assigneesRequired
Install
Works on UserTasks cloud and on any self-hosted instance. Installing creates the assets above; nothing runs until you complete setup and start it.
curl -fLO https://usertasks.com/gallery/servicenow-change-approval-1.0.0.utpkg
usertasks packages inspect servicenow-change-approval-1.0.0.utpkg # offline: checksum, hashes, signature
usertasks packages install servicenow-change-approval-1.0.0.utpkg --dry-run
usertasks packages install servicenow-change-approval-1.0.0.utpkg # prompts for each requirement
usertasks packages install servicenow-change-approval-1.0.0.utpkg --keep-incomplete --yes # in CI; finish with:
usertasks packages complete servicenow-change-approval -f values.yamlVerify the download
shasum -a 256 servicenow-change-approval-1.0.0.utpkg should print the file SHA-256. How gallery packages are signed.
Versions
Installing a newer version upgrades in place: local credentials and requirement values are kept, and changes you made are flagged first. How packages work
More packages
IT & Security Official
Monitoring alerts open prioritised ITSM incidents automatically; repeat alerts are deduplicated and P1/P2 incidents page the on-call engineer with escalation.
Needs:REST APIAssigneesInbound webhook
IT & Security Official
SIEM alerts are enriched with IP reputation, user and asset context, then auto-closed, opened as a SOAR case, or contained after analyst approval.
Needs:REST APIAssigneesInbound webhook
IT & Security Official
ServiceNow posts a new or escalated incident; the criteria table flags major incident candidates and the incident manager declares major or not.
Needs:REST APIInbound webhookAssigneesEmail