Integration brief · CentralSquare ← Back to the page   Print or save as PDF
Integration brief CentralSquareCase and Records Management

The Call for Service Attached to the Recording

This connector is not prebuilt. It would be built to your requirement on the REST API and ingestion path the platform already uses for dispatch and records systems, with scope and effort agreed per engagement. CentralSquare CAD is dispatch software widely used by small and mid-sized agencies, which is the setting where nobody has staff to spend on filing. Incident records coming across is what makes a recording findable by its call rather than by memory.

What you can do together

  • Retrieve every recording on a call by its incident number, without knowing who was on shift.
  • Have the incident number, unit and location land as attributes on ingest rather than being typed in later.
  • Assemble the media for one call with a workflow when a request or a review needs it.
  • Find recordings that matched no incident, which is the check a small agency rarely has time to run by hand.

How it connects

Incident and dispatch records would come across from CentralSquare over its API: the call for service, the units assigned, the times and the location. Those identifiers would arrive as custom attributes on the media, so the incident number is part of the evidence record rather than a note beside it.

Matching would be by time and unit, because both sides hold those two facts. A body camera recording carries its start time and the device it came from, and the incident timeline carries the units and their times, so correlation happens on ingest. An engagement would settle the awkward cases before they arise: two units on scene inside the same minute, a device with clock drift, a recording that starts before the call was created.

CentralSquare would stay the system of record for the incident, and dispatch would not change. A workflow could act on the result, most usefully by finding the recordings that matched nothing, which in a small agency is where a misconfigured device is discovered.

VIDIZMO and CentralSquare · Integration briefPage 1 of 2
How it works CentralSquareCase and Records Management

A scenario

  1. ScopingThe engagement would agree which incident fields come across and what the rule is when two units match the same recording.
  2. SetupThe connection would be configured once against the CentralSquare API with the attribute mapping.
  3. End of shiftRecordings ingest and correlate to their calls, the incident number arriving as an attribute under the library's retention and access control.
  4. A complaintA supervisor searches the incident number and has every unit's footage in one place within a minute.
  5. MonthlyA workflow lists unmatched recordings, and a camera whose clock had drifted by four minutes is corrected.

What stays where

CentralSquare remains the system of record for dispatch

Calls, units and timelines stay there, and dispatchers work as they do now.

The incident number travels with the evidence

It arrives as an attribute under the custody model and survives export.

Nothing is written back

The connection reads from CentralSquare; any write-back would be its own scoped work.

Processing runs where you deploy the platform

Shared or dedicated SaaS, your own cloud, on premises, or air-gapped, with a network path to CentralSquare where it is hosted.

Products and solutions

Next step

See it on your own CentralSquare instance.

We will show the connection made, the data moving and the output, then size it for your deployment.

Contact VIDIZMO

sales@vidizmo.ai

+1 571-969-2180

vidizmo.ai

Product names and logos are the property of their respective owners.Page 2 of 2