Turning a Ticket Into an Approval Step
Creating the ServiceNow record was the easy part. The awkward failure came later: an approval arrived after two runs were waiting, and the callback had too little information to say which one should resume.
We kept the ticket number, source incident ID, and pause record together. The callback had to identify the exact waiting run, carry the decision, and pass the state check. Approval resumed one action; rejection closed the waiting path without pretending containment had happened.
That is the boundary worth keeping. ServiceNow owns the human decision. XDR owns the response. The integration only carries a narrow, correlated signal between them.
The workflow can create a ServiceNow incident quickly. The hard part begins when the ticket becomes an approval boundary for a paused XDR response. The two systems need one correlation key, clear ownership, and an honest answer when either side is unavailable.
Create the record with a waiting state
The XDR workflow prepares a structured payload containing the source incident, affected asset, evidence, proposed action, and pending_approval state. The documented workspace pattern uses an HTTP POST to the ServiceNow incident target, then a separate XDR status/work-note action. The Business Rule/webhook callback described here is a generalized extension, not a claim that every deployment exposes the same endpoint.
XDR incident
-> stable correlation key
-> ServiceNow incident: pending approval
-> approver changes state
-> controlled callback
-> XDR validates and resumes
Make retries boring
The callback is idempotent. Store the event key and consumed timestamp. If ticket creation times out, search by correlation key before POSTing again. If remediation succeeds but the ticket update fails, reconcile the ticket without repeating remediation.
| Failure | Safe response |
|---|---|
| POST timeout | Lookup before retry |
| Approval callback repeats | Return prior result |
| XDR resume fails | Keep approval consumed; queue reconciliation |
| Work note fails | Preserve action result separately |
| Ticket closed early | Require explicit policy for reopen/new case |
Authentication stays one-way and narrow: ServiceNow signals a decision; it does not receive XDR response credentials. The audit record carries the request ID, ticket number, approval reference, callback result, and final action state.
What we implemented versus what we designed
The workspace documents and exports the ServiceNow POST, structured payload generation, XDR work notes, incident status update, retries, and reconciliation decisions. The Business Rule-to-webhook approval loop is the reusable design pattern layered on top; its exact ServiceNow configuration and callback transport must be validated in the target environment.