Introduction

The xMatters ServiceNow integration connects ServiceNow incident management and workflow automation with xMatters’ alerting and response capabilities. In a typical enterprise environment, ServiceNow may identify and manage an incident, while xMatters is responsible for rapidly engaging the right on-call people, sending notifications across multiple channels, and coordinating response actions.

This distinction becomes important in production projects. Creating an incident in ServiceNow is only the beginning of incident resolution. If a production database, API gateway, payment service, or business-critical application fails at 2:00 AM, the organization needs more than an incident record. It needs a mechanism to identify the appropriate responders, notify them quickly, escalate when there is no response, and keep the incident record synchronized.

The ServiceNow-xMatters integration provides that operational bridge.

Current xMatters documentation identifies several integration approaches, including the newer ServiceNow (Flow Designer) v2 workflow, the earlier ServiceNow Flow Designer integration, and the legacy direct integration. For new implementations, xMatters recommends the Flow Designer v2 workflow paired with the Everbridge Flow Designer app for ServiceNow.

This article explains the architecture, prerequisites, implementation approach, sample incident flow, testing strategy, common errors, and consultant-level best practices.

What Is the xMatters ServiceNow Integration?

At a high level, the integration connects two different responsibilities:

For example, consider a production application outage.

A monitoring platform detects that an application endpoint has stopped responding. The event reaches ServiceNow and creates or updates an incident. Based on incident priority and assignment group, the workflow sends relevant incident information to xMatters.

xMatters then determines who should be contacted.

The responder might receive:

• Mobile push notification

• SMS

• Email

• Phone call

• Other configured communication channels

The responder can acknowledge the alert or participate in an automated response workflow.

The objective is not simply to send another notification. The objective is to reduce the time between incident detection, human engagement, decision-making and remediation.

xMatters describes this as a continuous operational workflow covering signal, context, decision, orchestration, response and resolution.

Why Use xMatters with ServiceNow?

ServiceNow is often the system of record for enterprise IT service management. However, an incident record by itself does not guarantee that the right engineer will respond immediately.

A production incident may require:

1. Identifying the correct support group.

2. Determining the current on-call engineer.

3. Sending an urgent notification.

4. Escalating if the first responder does not acknowledge.

5. Capturing the response.

6. Updating the ServiceNow incident.

7. Coordinating additional technical teams.

This is where xMatters becomes useful.

For example:

A P1 payment API incident is created in ServiceNow and assigned to the Payments Support group.

Instead of relying on an engineer to notice the ServiceNow queue, the integration can send the incident information to xMatters. xMatters then uses its notification and on-call logic to engage the appropriate responders.

This is particularly useful for:

• 24×7 support teams

• Cloud operations

• SRE teams

• Network operations

• Database support

• Cybersecurity operations

• Application support

• Major Incident Management

Real-World xMatters ServiceNow Integration Use Cases

Use Case 1 – P1 Production Incident

Suppose an enterprise runs a customer-facing ordering application.

A monitoring system detects that the application is unavailable.

The workflow is:

Monitoring Tool
      |
      v
ServiceNow Incident
      |
      v
Incident Priority = P1
      |
      v
ServiceNow Flow
      |
      v
xMatters
      |
      v
On-Call Application Team
      |
      v
Acknowledgement
      |
      v
Incident Updated

The integration can pass information such as:

• Incident number

• Short description

• Description

• Priority

• Impact

• Urgency

• Assignment group

• Service

• Configuration item

• Incident URL

The responder receives enough context to decide whether immediate action is required.

Use Case 2 – Major Incident Response

A major incident often involves multiple teams.

For example:

• Application team

• Database team

• Network team

• Cloud infrastructure team

• Security team

ServiceNow can act as the central incident record, while xMatters coordinates communication with responders.

xMatters also documents a Major Incident Enhancement integration that can trigger xMatters alerts when a major incident is accepted or detected in ServiceNow. That particular enhancement is described as an xMatters Labs/community-supported integration rather than an officially supported xMatters integration, so organizations should assess support requirements before adopting it.

Use Case 3 – Automated Escalation

Consider an incident where the first responder does not acknowledge the alert.

A practical escalation model could be:

P1 Incident
     |
     v
Primary On-Call
     |
  No Response
     |
     v
Secondary On-Call
     |
  No Response
     |
     v
Technical Lead
     |
  No Response
     |
     v
Incident Manager

The advantage is that escalation logic does not depend on someone manually checking the ServiceNow queue.

Architecture of the ServiceNow and xMatters Integration

A simplified architecture looks like this:

+----------------------+
| Monitoring / Events  |
+----------+-----------+
           |
           v
+----------------------+
|      ServiceNow      |
|      Incident        |
+----------+-----------+
           |
           v
+----------------------+
|    Flow Designer     |
+----------+-----------+
           |
           v
+----------------------+
|       xMatters       |
| Alert / Workflow     |
+----------+-----------+
           |
     +-----+-----+
     |     |     |
     v     v     v
   Push  SMS   Phone
     |
     v
 Responders
     |
     v
 Response / Action
     |
     v
 ServiceNow Incident

In the Flow Designer approach, ServiceNow sends information to xMatters, and xMatters processes the incoming event through its workflow.

The xMatters documentation describes the Flow Designer integration as sending a JSON-formatted webhook to xMatters. A ServiceNow trigger in xMatters parses that webhook and starts the relevant flow.

The payload therefore becomes an important integration contract.

A simplified example might look like:

{
  "number": "INC0010045",
  "short_description": "Payment API unavailable",
  "priority": "1",
  "impact": "1",
  "urgency": "1",
  "assignment_group": "Payments Support",
  "service": "Payment API",
  "description": "Production API is returning HTTP 503 errors"
}

The exact payload structure should follow the integration workflow and version being implemented rather than assuming that this example is the vendor-defined payload.

Prerequisites

Before building the integration, confirm the following.

1. ServiceNow Instance

You need an appropriate ServiceNow instance with access to:

• Flow Designer

• Relevant integration functionality

• Incident tables

• User and group information

• Required application/plugin components

ServiceNow’s IntegrationHub capabilities provide integration steps that can communicate with external systems. ServiceNow documentation describes IntegrationHub as an integration framework that can connect Flow Designer workflows to external applications and services.

2. xMatters Account

You need an xMatters environment with permission to:

• Create or import workflows

• Create integration users

• Configure endpoints

• Manage users and groups

• Configure notification devices

• Review event and execution logs

3. Integration User

Use a dedicated technical identity rather than a personal administrator account.

This makes:

• Auditing easier

• Credential rotation easier

• Troubleshooting easier

• Ownership clearer

4. Network and Security Requirements

Validate:

• HTTPS connectivity

• Authentication

• Endpoint accessibility

• IP restrictions

• Firewall rules

• Credential management

• TLS requirements

5. Integration Design

Before configuration, document:

• Which incidents trigger xMatters

• Which priorities are supported

• Which assignment groups participate

• Which fields are transmitted

• Who receives each notification

• Escalation rules

• Response actions

• Error handling

Do not start configuration before defining these rules.

Step-by-Step xMatters ServiceNow Integration Build

Step 1 – Choose the Integration Model

For a new implementation, evaluate the ServiceNow (Flow Designer) v2 workflow first.

xMatters currently recommends this approach for new ServiceNow integrations because it provides more out-of-the-box functionality and integrates with the newer Everbridge Flow Designer app.

Avoid designing a new project around a legacy integration simply because an older environment already uses it.

Step 2 – Prepare ServiceNow

If the selected implementation requires an application from xMatters, install the appropriate application using the organization’s normal ServiceNow application-management process.

For the legacy xMatters application, xMatters documents installation through the ServiceNow Store and then through:

System Applications → Applications → Downloads

The legacy documentation also specifies integration roles for REST communication.

For a new project, however, validate the current v2 installation procedure instead of copying legacy installation instructions.

Step 3 – Create a Technical Integration User

Create a dedicated ServiceNow user for integration traffic.

For example:

The principle is least privilege.

Do not give a technical integration user admin simply because it makes initial testing easier.

Step 4 – Configure xMatters Integration User

Create a dedicated xMatters integration identity.

The xMatters documentation describes an integration user with the appropriate REST Web Service User role for authentication when requests are made from ServiceNow to xMatters.

Store credentials securely.

Do not place passwords directly into:

• Flow scripts

• Payloads

• Business rules

• Log statements

• Documentation screenshots

Step 5 – Import or Configure the Workflow

For the v2 implementation, configure the ServiceNow Flow Designer workflow in xMatters.

The workflow contains the integration logic required to process ServiceNow events.

At this stage, identify:

• Trigger endpoint

• Authentication

• Event properties

• Workflow inputs

• Response handling

• Recipient determination

Step 6 – Configure the ServiceNow Flow

Navigate to:

All → Flow Designer

Create or modify the flow according to the organization’s incident requirements.

A practical trigger could be:

Table: Incident
Condition:
Priority = 1
AND
Active = true
AND
Assignment Group = Payments Support

Avoid triggering notifications for every incident.

If 10,000 low-priority incidents are generated each month, sending every one to an on-call system creates alert fatigue.

Step 7 – Build the Incident Payload

Map only the fields required by xMatters.

Example:

{
  "incident_number": "${number}",
  "priority": "${priority}",
  "short_description": "${short_description}",
  "assignment_group": "${assignment_group}",
  "service": "${business_service}",
  "incident_url": "${incident_url}"
}

A common implementation mistake is sending the complete incident record.

That creates unnecessary data exposure and makes notifications difficult to read.

Use a controlled payload contract.

Step 8 – Configure Notification Logic

Define the response model.

For example:

These are example project rules, not universal defaults.

The correct values depend on the organization’s incident-management policy.

Step 9 – Configure Escalation

A practical escalation chain might be:

Level 1
Application On-Call
5 minutes

       ↓ no response

Level 2
Application Lead
5 minutes

       ↓ no response

Level 3
Incident Manager

Do not create aggressive escalation chains without understanding the organization’s support model.

The goal is to reach the correct person, not simply to notify more people.

Step 10 – Configure Response Actions

Where supported by the selected workflow, responders can perform actions associated with the incident workflow.

For example:

• Acknowledge

• Escalate

• Engage additional responders

• Initiate collaboration

• Update incident information

• Trigger remediation workflow

The available actions depend on the selected xMatters and ServiceNow integration version.

Testing the Integration

Never test the integration by immediately creating a real P1 production incident.

Use a controlled test case.

Test Case 1 – Basic Notification

Create a test incident:

Number: INC0010045
Priority: 1
Short Description: Test xMatters Integration
Assignment Group: Application Support

Expected result:

1. ServiceNow creates the incident.

2. Flow condition evaluates to true.

3. Payload is generated.

4. xMatters receives the event.

5. xMatters workflow executes.

6. Target responder receives notification.

Test Case 2 – Negative Condition

Create a P3 incident.

Expected result:

Incident Created
       |
       v
Flow Condition
       |
       v
Priority != P1
       |
       v
No xMatters Notification

This test is extremely important.

Integration testing should validate both when the workflow runs and when it does not run.

Test Case 3 – Escalation

Configure a test responder who does not acknowledge the notification.

Expected result:

Primary Responder
       |
       | No response
       v
Secondary Responder

Check timestamps carefully.

Test Case 4 – Incident Update

Update the incident description or priority.

Determine whether the business requirement expects:

• A new xMatters event

• An update to an existing event

• No notification

Do not assume every ServiceNow update should generate another notification.

Common Errors and Troubleshooting

Error 1 – Flow Does Not Trigger

Check:

• Flow activation status

• Trigger conditions

• Table

• Incident priority

• Assignment group

• User permissions

• Flow execution history

A frequent mistake is testing an incident that does not actually satisfy the trigger conditions.

Error 2 – xMatters Receives No Event

Check:

• Endpoint

• Authentication

• Network connectivity

• Payload

• Integration workflow status

• ServiceNow execution details

Compare the actual outbound request with the expected payload.

Error 3 – Wrong Person Receives Notification

This is usually a data or routing problem.

Check:

• Assignment group

• On-call configuration

• User synchronization

• Group membership

• User active status

• Device information

xMatters supports synchronization of ServiceNow users and groups in its integration architecture.

Error 4 – Duplicate Notifications

Suppose one incident creates five notifications.

Investigate:

Incident Created
      |
      v
Flow Trigger
      |
      v
Incident Updated
      |
      v
Flow Trigger Again

The solution is usually to make trigger conditions and correlation logic explicit.

For example, distinguish between:

• Initial incident

• Priority change

• Assignment-group change

• Major incident acceptance

Error 5 – REST Step Is Missing

If using ServiceNow Flow Designer and a required REST action is not available, check the IntegrationHub entitlement and required plugins.

ServiceNow community documentation notes that the REST action step is associated with IntegrationHub capabilities rather than being universally available in the base platform.

Do not modify scripts to work around a missing licensed capability before confirming the platform configuration.

Data Synchronization Considerations

User and group synchronization deserves special attention.

Imagine ServiceNow has:

Application Support
 ├── Ravi
 ├── Priya
 └── David

xMatters needs an accurate representation of the users and their notification information.

If Ravi leaves the team but remains active in the xMatters routing data, a P1 incident may still be sent to Ravi.

The xMatters documentation describes synchronization of ServiceNow users, groups and group members as part of the integration architecture.

Therefore, include synchronization validation in the implementation test plan.

Test:

• New user

• User update

• User deactivation

• Group creation

• Group membership change

• Group removal

Security Best Practices

Use Dedicated Integration Accounts

Never use an employee’s personal account.

Apply Least Privilege

Grant only the roles and access required for integration operations.

Protect Credentials

Use appropriate credential-management facilities rather than embedding credentials in scripts.

Minimize Payload Data

Do not transmit sensitive incident information unless required.

For example, instead of sending an entire description containing customer information, send:

Incident Number
Service
Priority
Short Description
Incident URL

The responder can then open ServiceNow for additional information.

Audit Integration Activity

Monitor:

• ServiceNow flow executions

• Failed executions

• xMatters workflow executions

• Notification delivery

• Authentication failures

• Synchronization errors

Consultant Best Practices for xMatters ServiceNow Projects

1. Start With the Incident Matrix

Before development, create a table like:

This prevents business rules from being hidden inside Flow Designer logic.

2. Design Idempotency

A single incident should not create uncontrolled duplicate alerts.

Use incident number and event identifiers to establish correlation.

3. Separate Business Rules From Integration Logic

Do not put every condition into one giant Flow.

Instead:

Incident Eligibility
        |
        v
Notification Routing
        |
        v
xMatters Integration
        |
        v
Escalation

This makes future maintenance easier.

4. Use Lower Environments

Build:

DEV
 ↓
TEST
 ↓
UAT
 ↓
PRODUCTION

Do not test new routing rules directly against production on-call groups.

5. Test Failure Scenarios

A successful API response is not enough.

Test:

• Authentication failure

• Invalid payload

• Timeout

• xMatters unavailable

• ServiceNow unavailable

• Inactive user

• Missing assignment group

• Duplicate incident event

• Network failure

6. Document the Integration Contract

Document:

• Endpoint

• Authentication method

• Payload

• Mandatory fields

• Trigger conditions

• Response

• Error handling

• Retry behavior

• Escalation rules

• Ownership

This becomes extremely valuable during production support.

How xMatters Fits Into a Larger Enterprise Architecture

A mature enterprise may have an architecture such as:

Cloud / Application Monitoring
            |
            v
      Event Management
            |
            v
        ServiceNow
            |
     +------+------+
     |             |
     v             v
  Incident      CMDB/Service
     |
     v
 Flow Designer
     |
     v
   xMatters
     |
 +---+---+---+
 |   |   |   |
Push SMS Phone Email
 |
 v
On-Call Engineers
 |
 v
Remediation

In larger environments, Oracle Fusion, OCI, cloud monitoring, middleware, and other enterprise applications may also generate operational events that eventually feed an IT service-management process.

For example, an integration failure in an Oracle-based enterprise application could result in an operational event being routed into ServiceNow, where the incident workflow determines whether xMatters escalation is required.

The important architectural principle is to avoid tightly coupling every application directly to every responder.

ServiceNow can provide the service-management system of record, while xMatters handles operational engagement.

FAQs

1. What is xMatters used for with ServiceNow?

xMatters can be used to extend ServiceNow incident processes with real-time notification, on-call engagement, escalation and workflow orchestration. ServiceNow manages the incident record, while xMatters helps engage the people or response workflows needed to address the incident.

2. Which xMatters ServiceNow integration should a new project use?

For a new implementation, xMatters currently recommends the ServiceNow (Flow Designer) v2 workflow with the Everbridge Flow Designer app rather than starting with the legacy direct integration. Existing organizations may continue to maintain older integrations depending on their requirements.

3. Can ServiceNow incidents trigger xMatters notifications automatically?

Yes. A ServiceNow workflow can identify incidents that meet defined conditions and send information to xMatters. The xMatters workflow then processes the event and determines the configured response, notification and escalation behavior.

Summary

The xMatters ServiceNow integration is most useful when an organization needs to move beyond simply recording incidents and establish a coordinated operational response.

A well-designed implementation separates responsibilities clearly:

• ServiceNow maintains the incident and service-management context.

• Flow Designer controls workflow logic inside ServiceNow.

• xMatters handles operational engagement, notification and escalation.

• Responders acknowledge and execute the required response.

• Monitoring platforms provide the initial signals.

For new implementations, evaluate the current ServiceNow (Flow Designer) v2 integration rather than automatically copying a legacy direct-integration design. xMatters explicitly recommends the v2 workflow for new ServiceNow integrations.

From a consultant perspective, the most important part is not simply making the API call work. The real implementation work is defining which incidents should generate alerts, who should receive them, how escalation works, what information is transmitted, how duplicates are controlled, and what happens when the integration fails.

For Oracle Cloud professionals working with enterprise integrations, Oracle’s current documentation hub provides the broader Cloud Applications documentation. For Oracle HCM implementations that exchange operational data with external applications, also refer to the current Oracle Fusion Cloud Time and Labor documentation and its 26A release information rather than relying on older release references.

Oracle Cloud Applications Documentation

Oracle Fusion Cloud Time and Labor – Using Time and Labor

Oracle Fusion Cloud Time and Labor 26A What’s New

Refer to the relevant current documentation before implementing integrations because endpoint behavior, supported integration approaches, application versions and release-specific capabilities can change.