Overview#
The Records Management System (RMS) Connectors module exports closed incident data from the platform to external law enforcement and public safety records management systems, ensuring that incident records are synchronised with the agency's official RMS without manual re-entry. The module provides native connectors for Tyler Technologies New World and Hexagon (formerly Intergraph), the two most widely deployed public safety RMS platforms, alongside a generic REST connector for agencies with custom or proprietary systems. Data exports use the CAP 1.2 (Common Alerting Protocol) and NIEM 6.0 (National Information Exchange Model) standards to maximise interoperability with downstream systems.
Key Features#
- Tyler New World Connector: Authenticates via OAuth 2.0 client credentials, automatically refreshing access tokens, and posts incident data to the Tyler API with embedded CAP 1.2 XML for rich incident context. Falls back to a static bearer token if OAuth is not configured
- Hexagon RMS Connector: Exports incidents in NIEM-JSON format to the Hexagon endpoint, supporting HTTP Basic, API key, or Bearer token authentication, matched to whatever method the agency's Hexagon deployment requires
- Generic REST Connector: A configurable connector accepting any HTTPS endpoint with Bearer, Basic, or unauthenticated access modes, enabling integration with custom-built or regional RMS systems beyond the named providers
- CAP 1.2 Standard Export: Tyler connector embeds a Common Alerting Protocol 1.2 body within the incident payload, validated against the OASIS XSD, enabling the receiving Tyler system to process the rich structured event data with no custom parsing required
- NIEM 6.0 JSON Export: Hexagon connector sends incident data formatted to the National Information Exchange Model 6.0 JSON specification, including IncidentID, SourceSystem identifier, NIEMVersion (4.2), field mapping, and the full NIEM export body
- Tenant-Configured Field Mapping: Both connectors support per-tenant field mapping so that platform incident fields can be aligned to the agency's RMS field names without changing the connector code
- Dry-Run Default: All connectors operate in dry-run mode by default: the full export payload is constructed and logged exactly as it would be transmitted, but no HTTP request is sent. Live transmission requires explicit activation through the RMS_LIVE_PUSH environment flag, preventing accidental RMS writes in test environments
- Exponential Backoff Retry: Failed transmissions are retried up to three times with delays of 0.5, 1, and 2 seconds, handling transient network issues without blocking the incident closure workflow
- Push Result Logging: Every export attempt, including dry-run builds, is recorded with the constructed payload, HTTP result, and any error detail, giving integration administrators full visibility into transmission status
Use Cases#
Automated Incident Synchronisation#
When an emergency dispatcher closes an incident in the platform, the RMS connector automatically exports the record to the agency's Tyler New World or Hexagon system. Incident data reaches the official records system within seconds of closure, eliminating the data entry backlog that accrues when personnel manually create RMS records at end of shift.
NIEM-Compliant Data Exchange#
An agency participating in inter-agency data sharing under NIEM standards uses the Hexagon connector to export incidents in NIEM 6.0 JSON format, enabling automatic ingestion by partner agencies' systems and meeting federal reporting compliance requirements.
Custom Agency Integration#
An agency running a bespoke records management system uses the generic REST connector. They configure the endpoint URL, select Basic authentication, and define a field mapping that aligns the platform's incident schema to their system's expected payload structure, no custom development required.
Pre-Production Validation#
Before enabling live RMS transmission, the integration team uses dry-run mode to inspect the exact payload that would be sent for real incidents. They validate field mapping, confirm CAP or NIEM formatting, and verify authentication headers, all without risking any data appearing in the production RMS.
Post-Transmission Audit#
An agency administrator queries the push result log to confirm that all incidents closed during a specific shift were successfully transmitted to the RMS, identify any that failed, and view the exact error returned by the RMS system for failed attempts.
How It Works#
Integration#
RMS Connectors are invoked by the Incident Management module on incident state transitions that trigger an export event (typically incident closure or a specific status change defined by the tenant). Connector configuration, endpoint URL, authentication credentials, field mapping, and active connector type, is managed per organisation through the administration console and stored in the tenant configuration record. The push result is recorded on the incident record and visible in the incident detail view, allowing dispatchers and supervisors to see RMS transmission status alongside the incident timeline.
Supported Standards#
- CAP 1.2: OASIS Common Alerting Protocol, validated against XSD schema
- NIEM 6.0 JSON: National Information Exchange Model, structural validation included
- NIEM 4.2 version identifier: Used in Hexagon payloads for downstream system compatibility
Open Standards#
- CAP 1.2 (OASIS Common Alerting Protocol): The Tyler New World connector embeds a CAP 1.2 XML body within the incident payload, validated against the OASIS XSD, enabling the receiving system to ingest rich structured event data without custom parsing.
- NIEM 6.0 JSON (National Information Exchange Model): The Hexagon connector serialises incident records to the NIEM 6.0 JSON specification, including a NIEMVersion identifier and full field mapping, supporting inter-agency data sharing and federal reporting compliance.
- OAuth 2.0 Client Credentials (RFC 6749): The Tyler connector authenticates via the OAuth 2.0 client credentials grant, automatically fetching and refreshing bearer tokens from the configured token endpoint before each transmission.
- HTTP Basic Authentication (RFC 7617): The Hexagon connector supports HTTP Basic authentication, base64-encoding credentials into the Authorization header as specified by RFC 7617, matching the authentication method required by many agency Hexagon deployments.
- Bearer Token Authentication (RFC 6750): All three connectors support Authorization: Bearer token headers as defined by RFC 6750, used as the primary auth mode for generic REST endpoints and as a fallback for both named connectors.
- JSON (ECMA-404 / RFC 8259): All connector payloads are transmitted as JSON over HTTPS, with Content-Type and Accept headers set to application/json, ensuring interoperability with standard REST endpoints across all three connector types.
Last Reviewed: 2026-04-14 Last Updated: 2026-04-14