xmatters/xm-labs-integrationhub

Purpose and delivery model

This repository packages a no-code/low-code inbound integration from ServiceNow to xMatters. It is primarily a deployable configuration bundle, not an application codebase: ServiceNow detects table-record events, IntegrationHub POSTs event data to an xMatters inbound workflow, and xMatters creates notifications/events. Key artifacts are ExampleWorkflow.zip, UpdateSet.xml, and EmailMessageTemplate.html.

Entry points and installation paths

Two provisioning paths establish the integration:

• Import the xMatters plan/workflow from ExampleWorkflow.zip; its configured inbound integration exposes the request URL consumed by ServiceNow.

• Either manually create ServiceNow credentials, HTTP connection alias, action, and flow, or import the prebuilt ServiceNow configuration from UpdateSet.xml.

The user-facing notification format can be adapted through EmailMessageTemplate.html.

ServiceNow event trigger stage

A ServiceNow Flow Designer flow is the source-side runtime entry point. It can subscribe to created/updated records from any selected ServiceNow table, with conditions such as assignment-group changes. The packaged example is represented in UpdateSet.xml; the README’s example centers on an Incident trigger. This boundary is responsible for deciding which record changes become outbound notifications.

IntegrationHub action and payload construction

The flow invokes a reusable IntegrationHub Action containing a REST step. The action maps trigger data into a JSON request body, typically with:

• recipients: target xMatters group

• properties: arbitrary ServiceNow fields used by the xMatters workflow

The flow/action configuration is distributable in UpdateSet.xml; the expected notification/body presentation is exemplified by EmailMessageTemplate.html. Payload mapping is configured in ServiceNow’s GUI rather than maintained as source code here.

Authentication and HTTP boundary

ServiceNow owns connectivity through a Connection & Credential Alias: HTTP POST, Content-Type: application/json, and Basic Auth using an xMatters REST Web Service User. The connection URL is the xMatters inbound-integration URL, ideally held outside the action for reuse across actions. Credentials and instance-specific URLs must be replaced after importing UpdateSet.xml; they should not be treated as portable package defaults.

xMatters inbound workflow stage

xMatters is the downstream event-processing runtime. Its imported workflow accepts the POST, parses the JSON payload, applies defaults such as recipient groups, creates an xMatters event, and sends email/push notifications with configured response options. The workflow and inbound script/configuration are encapsulated in ExampleWorkflow.zip; EmailMessageTemplate.html supplies a customizable message template artifact.

Operational flow and verification

Control flow is: ServiceNow record mutation → Flow trigger/conditions → IntegrationHub Action → authenticated HTTP POST → xMatters inbound workflow → recipient notification. Operators validate the ServiceNow action/flow with Flow Designer’s test capability, then inspect the xMatters inbound integration Activity Stream for POST success and resulting notifications. The principal external dependencies are a licensed ServiceNow IntegrationHub instance and an xMatters tenant with workflow import and REST-user access.