ITSM Bridge

Scope

Ticketing lives in Cadres Beacon or your existing ITSM platform; Relay forwards operational events over a permanent bridge and reads ticket status back. This public guide keeps the operating model and removes private endpoint and route detail.

Step-by-step guides for connecting an external ITSM platform, forwarding Relay events, reading remote ticket status, and recovering the bridge.

Related documents:

The bridge connects Relay to one external ITSM platform per account and forwards incident and change events to it, then reads the remote ticket status back onto Relay entities. You need integrations.manage to configure it, integrations.view to inspect it, and approvals.decide to act on the approvals inbox.

Connecting A Platform (Overview)

1. Open Settings → ITSM Bridge (pages/settings/ItsmBridge.tsx).
2. Pick a provider. The credential + config form is rendered from the provider’s
3. Fill in the base URL, credentials, and any provider config.
4. Save with Active on. Only one active ITSM integration is allowed per account;
5. Enable per-org forwarding and set remote org references (section 3).

Secrets are write-only: once saved, the form shows a masked placeholder and never returns the stored value. Leave a secret field blank/masked on edit to keep it.

Enabling Forwarding

Per-org enable + remote org mapping

For each customer org that should forward to the ITSM, set its org setting

• is_enabled — forwarding is on by default; set false to mute a specific org.

• remote_org_ref — the vendor’s company/account identifier for that org (stamped on created tickets: ServiceNow company, Beacon data.organization_external_ref, …).

• suppress_alert_notifications — default false. When true and this org has active ITSM forwarding, Relay stops sending its own alert notifications for the org so operators paged through Beacon’s escalation engine are not double-paged. Leave it off unless Beacon owns paging for that org.

Native incident forwarding

Native Relay alert incidents forward only when the org opts in

• forward_incidents — default off. only incidents at or above it forward.

Change events (change.recorded, etc.) forward automatically from the patch/cert/ compliance/rollout seams when an org is enabled — they are not gated by the incident forwarding toggle. With no active integration everything is discarded cheaply.

Reading Remote Status

Once a ticket exists remotely, its coordinates show as a link chip on the Relay detail page for the source record — alert incident, patch deployment, ransomware incident, compliance violation, cert renewal, and agent rollout. The chip shows the remote key (e.g. INC-123), the canonical status, and a deep link to the remote chip means no link (no integration, org disabled, or the event was filtered out).

Optional ITSM Change-Approval Gate

The platform’s own approval gate is always authoritative for patch/remediation runs. Optionally, a ring-set/policy can additionally require the connected ITSM to approve the change:

• Set itsm_approval_required on the ring-set/policy. When an integration is active, a gated deployment waits until the change ticket’s remote status reads back approved (via the entity link — never a synchronous remote call), then proceeds; a remote rejected blocks it.

• It has a per-policy timeout and an operator override — approve the deployment from the Relay approvals inbox (approvals.decide) to release it without waiting for the ITSM.

• With no active integration the flag is inert — the deployment gates only on the platform approval, deterministically.

To decide a pending approval: Approvals inbox → open the request → Approve or

Health And Recovery

Health card

The integration’s health card shows health_status the last 100 completed deliveries × 100), circuit-breaker state, and delivery/failure counters. Health is recomputed after each delivery batch and by the 5-minute sweep.

Recovering a tripped circuit breaker

The breaker opens after 5 consecutive delivery failures; while open, new deliveries are recorded circuit_broken and not attempted. It self-heals: after 5 minutes it goes half_open and the next delivery is a single probe — success closes it, failure re-opens it.

To recover immediately after fixing the root cause (e.g. rotated credentials, vendor back up): Reset circuit breaker dead-letter retry (below) to flush the backlog.

Dead-letter retry

Failed deliveries collect in the dead-letter queue retry re-queues the row immediately and, if attempts were exhausted, gives it a fresh existing remote ticket rather than creating a duplicate.

Pausing

preserving config and queued rows (held, not failed, and not consuming attempts). Resume with the same toggle. Use this during vendor maintenance.