ServiceNow and Jira Sync for Stations, Vehicles, and IT

Overview#

Operational signals from stations, vehicles, responder mobiles, and IT health checks should not stop at a chat message or a verbal handover. When something breaks, the right ticket needs to exist in the system that the maintenance team already lives in, and the watch-commander needs to see that ticket against the affected asset before assigning it to the next job.

The Facilities and IT Sync module connects Argus to ServiceNow and Jira so that station alarms, fleet telematics fault codes, equipment-bay defects logged on the responder mobile, IT health-check failures, and dispatcher-reported station issues automatically open tickets against the correct asset. Ticket state changes flow back to Argus, so a watch-commander sees outstanding maintenance against a vehicle before deploying it, and ticket closure lands on the canonical incident timeline if the originating job is still open.

Last Reviewed: 2026-05-05 Last Updated: 2026-05-05

Key Features#

• Asset-Linked Ticket Creation: Tickets are opened against the specific vehicle, station, equipment item, or IT asset that produced the signal, not against a generic queue.

• Multi-Source Signal Capture: Station alarms, telematics fault codes, mobile-logged equipment defects, IT health-check failures, and dispatcher-reported issues all flow through a single ticketing path.

• Bidirectional State Sync: Ticket creation, status updates, and closure in ServiceNow or Jira are mirrored locally, so Argus reflects the live maintenance picture without manual rekeying.

• Watch-Commander Visibility: Outstanding maintenance against vehicles and stations is surfaced before assignment decisions, so a vehicle with an open defect ticket is not silently sent to the next job.

• Incident Timeline Linkage: When a ticket originates from an active dispatch, the ticket reference is logged on the canonical incident timeline, and closure lands on the same timeline if the incident is still open.

• ServiceNow and Jira Coexistence: Either or both back-ends can be configured per asset class, supporting environments where facilities use ServiceNow while IT defects route to Jira.

• Local Mirror for Resilience: A mirror table preserves ticket state in Argus so operational views keep working during partner-system outages and reconcile on reconnect.

Use Cases#

• Equipment Failure Mid-Dispatch: A defibrillator fault is logged on the responder mobile during a job, a ServiceNow ticket is auto-created against that vehicle, and the watch-commander sees the open ticket before reassigning the unit.

• Fleet Telematics Fault Code: A vehicle reports a diagnostic trouble code, a ticket is opened against the vehicle record, and the next deployment decision reflects the maintenance status.

• Station Alarm Routing: A facility alarm at an ambulance station opens a ServiceNow facilities ticket against the station record without requiring a duty officer to phone it in.

• IT Health-Check Failure: A failing dispatch console health check raises a Jira issue against the affected IT asset and notifies the on-call IT team automatically.

• Dispatcher-Reported Station Issue: A dispatcher flags a heating fault at a station from the operational console, and a facilities ticket is opened with the originating dispatcher recorded as the requester.

• Maintenance Lineage on Incidents: A reviewer reading the canonical incident timeline sees the equipment failure, the resulting ticket reference, and the eventual closure stamp without leaving the incident record.

Integration#

• ServiceNow Now Platform: Tickets are created, updated, and closed through the ServiceNow REST API using a configurable table mapping per asset class.

• Jira Cloud and Data Center: Issues are created and synced through the Jira REST API, with project and issue type configurable per asset class.

• Webhook Framework: Inbound state-change webhooks from ServiceNow and Jira are validated and dispatched through the existing Argus webhook service for consistent signature verification and audit.

• Connector Registry: ServiceNow and Jira adapters are registered through the existing connector framework so that credentials, environment scoping, and health checks share the platform-wide pattern.

• Facility and Asset Records: Ticket records are linked to the canonical station, vehicle, and equipment entries already managed for facilities and asset visibility.

• Watch-Commander Console: An outstanding-tickets overview appears in the admin surface so that maintenance status is visible alongside the live operational picture.

• Canonical Incident Timeline: Ticket-created and ticket-closed events are emitted as CloudEvents and recorded on the linked incident timeline when the ticket originated from an active dispatch.

Open Standards#

• OpenAPI 3.1: ServiceNow Now Platform and Jira REST APIs are documented as OpenAPI 3.1 consumers so that contract changes are tracked and regenerated against the published schemas.

• AsyncAPI 2.6: The ticket-state-change channel is described using AsyncAPI 2.6 so that downstream consumers of state events have a versioned contract.

• CloudEvents 1.0: Ticket lifecycle is emitted as CloudEvents using argus.facility.ticket_created, argus.facility.ticket_updated, and argus.facility.ticket_closed types.

• OAuth 2.1: Authentication to ServiceNow and Jira uses OAuth 2.1 flows so that token handling follows the current best-practice profile.

• mTLS RFC 8705: Mutual-TLS client authentication is supported for service-to-service connections where the partner system accepts it.

• Standard Webhooks (HMAC SHA-256): Inbound webhooks from ticket systems are validated using HMAC SHA-256 signatures following the Standard Webhooks pattern.

• ITIL 4: Ticket flows align with ITIL 4 incident, problem, and change management process patterns so that operational practice maps onto the partner systems already in use.

• SCIM 2.0 (RFC 7643/7644): Where ticket assignees are managed centrally, user lifecycle sync uses SCIM 2.0 so that joiners, movers, and leavers stay consistent across systems.