Xurrent IMR Connector

Alpha: this connector is available as Xurrent IMR Connector - Alpha. Its actions and fields may change before general availability.

Overview

Connects Xurrent iPaaS runbooks to Xurrent IMR (formerly Zenduty) for incident management and response. Runbooks can create, update, read and search incidents, add notes, raise alerts, look up who is on call, and list teams and services. A webhook trigger starts a runbook whenever an incident is triggered, acknowledged or resolved in Xurrent IMR.

Prerequisites

• A Xurrent IMR account with API access.
• A Xurrent IMR API token, created in the Xurrent IMR account settings.
• For the Create Alert action, the integration key of the service integration that should receive the alert.
• For the Incident Webhook trigger, permission to configure an outgoing webhook integration in Xurrent IMR.

Authentication

Outbound connection (actions)

Inbound connection (trigger)

The trigger endpoint can be secured in two ways. Both are optional, but if neither is configured the endpoint accepts any request, so configure at least one.

Triggers

Incident Webhook

Starts a runbook when Xurrent IMR sends an incident event through an outgoing webhook. Supported event types: triggered, acknowledged and resolved.

Setup: create the inbound connection in iPaaS, then configure an outgoing webhook integration in Xurrent IMR that posts to the trigger endpoint. Add the webhook secret or basic auth credentials on both sides.

The incident's unique_id is used as the job context identifier, so all jobs for one incident can be found together.

Output

The job fails if the request has no body, the body is not a JSON object, or it contains no incident data.

Actions

Incident management

Create Incident

Creates a new incident.

Output: unique_id, incident_number, title, summary, status, creation_date, urgency, assigned_to, assigned_to_name, incident_key.

Update Incident

Updates an existing incident. Only the fields you fill in are changed.

Output: same fields as Create Incident.

Get Incident

Retrieves one incident by its incident number.

Output: same fields as Create Incident.

List Incidents

Searches incidents with filters. Returns one page per iteration; the action continues while has_next_page is true.

Output: has_next_page, and incidents, a list with unique_id, incident_number, title, summary, status, urgency, creation_date, resolved_date, acknowledged_date, assigned_to, assigned_to_name, service, escalation_policy, incident_key.

Add Incident Note

Adds a note to an existing incident.

Output: unique_id, note, creation_date, user.

Alert management

Create Alert

Sends an alert to a service integration through the Xurrent IMR Events API. Depending on the integration's rules, the alert creates a new incident or is added to an existing one.

Output: unique_id, incident (incident number), incident_created, entity_id, alert_type, message.

Team and service management

Get On-Call

Returns who is currently on call for a team, per escalation policy.

Output: escalation_policies, each with unique_id, name and oncalls (escalation rules with position, delay and the on-call users' username, first_name, last_name, email).

List Teams

Lists all teams in the Xurrent IMR account. No input.

Output: teams, each with unique_id, name, owner, creation_date.

List Services

Lists the services of a team.

Output: services, each with unique_id, name, team, status, escalation_policy, summary.

Rate Limiting and Error Handling

A response that is not valid JSON also fails the job.

Best Practices

• Always secure the trigger endpoint with a webhook secret or basic auth. Without either, anyone who knows the URL can start the runbook.
• Use List Teams and List Services once to find the unique IDs that Create Incident, Get On-Call and List Incidents need, and store them as runbook variables.
• Set entity_id on Create Alert so repeated alerts for the same problem are grouped into one incident instead of creating many.
• Use Get Incident with the incident number, and Update Incident with the unique ID. The two identifiers are different.
• Branch on event_type in runbooks that start from the Incident Webhook trigger, because one endpoint receives triggered, acknowledged and resolved events.

Common Use Cases

• Create a Xurrent request when an incident is triggered in Xurrent IMR, and resolve it when the incident is resolved.
• Raise an alert in Xurrent IMR from a monitoring or ITSM event with Create Alert.
• Look up the on-call engineer for a team and assign or notify them from a runbook.
• Add notes to an incident as related work progresses in other systems.
• Build a periodic report of open incidents with List Incidents.

References

• Xurrent IMR
• Zenduty API documentation
• Zenduty outgoing webhooks