Documentation Map
Pick by problem. Each route lands on the page that actually answers the question, not a landing page that defers again.
Route By Intent
| I need to… | Start here | Then |
|---|---|---|
| decide if this integration is the right fit | Capabilities | Use cases |
| stand up the ServiceNow side | ServiceNow Setup | Handler Script |
| stand up the RHACS side | RHACS Setup | Webhook Payload |
| understand what the handler actually does with a payload | Handler Script | Incident Fields |
| confirm which RHACS JSON fields the integration reads | Webhook Payload | Handler Script |
| map RHACS severity to ServiceNow urgency + impact | Severity Mapping | Incident Fields |
| triage an exec-into-pod violation end-to-end | Exec-into-Pod Triage | Handler Script |
| stop alert storms from overwhelming Incident | Dedup + Storm Control | Capabilities |
| troubleshoot “Description field not showing” in the Incident form | Incident Fields | — |
Page Types
| Type | Reads like | Examples |
|---|---|---|
| Setup | one-time install steps, ordered | ServiceNow, RHACS |
| Reference | field/line-level facts, scannable | Handler Script, Payload, Incident Fields |
| Capabilities | what integration does + refuses | Capabilities |
| Practical use case | operator workflow with problem + pattern | Exec-into-Pod, Severity mapping, Dedup |
Practical Use Cases
- Exec-into-Pod Triage — RHACS catches
kubectl exec, SNOW Incident lands with pod/container/user/command populated. - Severity → Urgency/Impact — adjust the handler switch so ITIL priority matches RHACS severity reality.
- Dedup + Storm Control — keep a noisy policy from opening a thousand Incidents during an incident.
Read Order For First-Time Setup
- Capabilities — confirm this integration matches what you actually need
- ServiceNow Setup — endpoint exists before RHACS can POST
- RHACS Setup — notifier + policy attachment
- Exec-into-Pod Use Case — smoke-test with a known trigger
- Severity Mapping — tune priority before real rollout