Skip to main content

Escalation Routing: Connecting to External Ticketing Systems

Keeptrusts connects escalations to external ticketing systems by routing risky interactions into /escalations, then using the current delivery surfaces such as /settings/webhooks and /approvals/configure to push those events into your own ticket bridge, ChatOps flow, or incident system; the console does not create Jira or ServiceNow tickets natively today, so the integration point is the webhook layer, not a built-in issue board.

Use this page when​

  • You need escalation events to create or update work in an external system.
  • You want reviewers to keep using Keeptrusts while ticket tracking lives elsewhere.
  • You need a practical integration path that matches the product as it exists today.

Primary audience​

  • Primary: Technical Engineers integrating review workflows with existing operations tooling
  • Secondary: Technical Leaders designing incident and approval routing

The problem​

Escalation workflows often fail at the handoff point. The governed system knows something needs review, but the people who operate incidents or approvals still live in another tool. That creates duplicate manual work.

A reviewer sees the item in Keeptrusts, then someone else copies context into a ticketing system, then yet another person updates status in both places. The result is slow and error-prone. Context gets lost, ownership is ambiguous, and the queue becomes a half-integrated process.

The wrong fix is pretending every external tool needs a fully native in-console page. In most organizations, what matters is a reliable bridge, not a perfect UI replica. Ticketing systems already exist. The real need is to move the right governed signals into them without losing the Keeptrusts review record.

The solution​

The current product gives you the right building blocks if you use them in the right order.

First, policy logic or approval policy determines what should escalate. That work still lives in managed configuration and review policy.

Second, the human review queue stays in Keeptrusts. /escalations and the related review pages remain the source of truth for claim, resolution, and governance notes.

Third, external routing happens through delivery surfaces:

  • /settings/webhooks for managed webhook endpoints, secret rotation, delivery logs, and test delivery
  • /settings/webhooks/new for adding a new endpoint
  • /approvals/configure for approval-notification delivery, including generic webhook delivery and ChatOps options such as Slack or Teams

That means the external system does not replace the Keeptrusts queue. It receives a structured signal from it.

Implementation​

The cleanest pattern is to separate decision, review, and delivery.

  1. Configure the policy or approval path that should escalate.
  2. Confirm that the item appears in /escalations or the related approval surface first.
  3. Add a webhook endpoint in /settings/webhooks/new for your ticket bridge or incident adapter.
  4. Use the test-delivery action in /settings/webhooks and inspect the delivery log before you depend on it operationally.
  5. If your process also relies on approval notifications, configure /approvals/configure so the approval workflow can post into the same or a related external channel.
  6. Let your bridge service create or update the external ticket and keep the Keeptrusts review URL in the external payload.

This is the critical design choice: the external system should receive a reference back to the Keeptrusts review surface, usually /escalations/{id}/review or the related approval path, rather than trying to duplicate every field and decision locally.

That way reviewers still resolve the item where the governance record belongs. The ticket system tracks broader operational work. The webhook bridge ties them together.

A practical workflow for a security-sensitive escalation looks like this:

  1. A governed interaction triggers escalation through the normal policy path.
  2. The item lands in /escalations.
  3. A webhook configured in /settings/webhooks forwards the event to your bridge.
  4. The bridge opens or updates a ticket in your external system.
  5. The ticket includes the Keeptrusts review URL, gateway or actor metadata, and any organization-specific severity mapping.
  6. The reviewer performs the actual governance resolution inside Keeptrusts.
  7. The ticket tracks follow-up remediation or cross-team coordination.

This design is also useful for ChatOps. If a full ticket is too heavy, /approvals/configure can deliver a generic webhook or Slack/Teams notification that still points reviewers back to the right Keeptrusts surface.

The important product boundary is honesty: Keeptrusts currently gives you real queueing, review, webhooks, test delivery, and approval notification surfaces. It does not give you a native Jira-specific board. If you design around the actual webhook boundary, the integration is robust. If you wait for a one-screen ticketing abstraction, you will probably keep the manual copy-paste workflow longer than necessary.

Results and impact​

Teams that integrate escalation routing this way usually cut the most expensive part of the workflow: manual relaying. Reviewers stay in the governance system. Operations teams keep using their ticketing system. The bridge handles the translation.

That makes ownership clearer. The Keeptrusts queue remains authoritative for review decisions. The external system remains authoritative for downstream operational work. Neither side has to fake being the other.

It also improves evidence quality because the review record stays attached to the actual governed object instead of being retyped into a ticket description.

Key takeaways​

  • Keeptrusts supports escalation handoff through webhooks and approval-notification delivery, not through a native Jira or ServiceNow issue page.
  • Keep the actual governance resolution in /escalations or the related approval surface.
  • Use /settings/webhooks for endpoint management, delivery testing, logs, and secret rotation.
  • Use /approvals/configure when approval notifications also need to reach external systems.
  • Make the external ticket point back to the Keeptrusts review URL instead of duplicating the whole workflow.

Next steps​