Motorola Solutions

How it connects

Case and report records would come across from Flex over its API, and the case number would arrive as a custom attribute on the media. Attribute mapping is what carries that identifier across the boundary, which matters because the case number is usually the only thing common to the records system, the evidence store and whatever the prosecutor uses.

Filing would follow the case rather than a folder someone chose. A recording, a statement or a scanned report would attach to the case it belongs to on ingest, and the library's own structure becomes a consequence of the case record rather than a parallel filing system that drifts from it. An engagement would settle the reverse direction too: whether a case closing in Flex should change retention on the evidence attached to it, which is the point where a records policy and an evidence store usually disagree.

Flex would stay the authoritative record for the case. A workflow could read it to assemble what a case file needs, or to check that every item a report references actually exists in the library, which is a different question from whether the library is tidy.

What you can do together

• File evidence against the case number from Flex on ingest, so nothing depends on a person choosing the right folder.
• Assemble what a case file needs with a workflow reading the Flex record, rather than someone working from a list.
• Check that every item a report references exists, and find the ones that do not before a disclosure deadline does.
• Carry the case number as an attribute so it survives export and transfer to a prosecutor.

A scenario

1. ScopingThe engagement would agree which case fields come across, how the case number maps to an attribute, and whether a case closing changes retention.
2. SetupThe connection would be configured once against Flex's API with that attribute mapping.
3. FilingAn interview recording ingests and attaches to its case number, under the library's access control, retention and custody record.
4. Preparing a fileA workflow reads the Flex case, assembles the media attached to it, and lists the items the report references that are not present.
5. HandoverThe case file goes to the prosecutor with the case number carried on every item, so nothing has to be re-identified at the other end.

What stays where

Products and solutions

• Nexus and AI Intelligence Hub
• Digital Evidence Management

Footage That Knows Which Call It Belongs To

This connector is not prebuilt. It would be built to your requirement on the REST API and ingestion path the platform already uses for records systems, with scope and effort agreed per engagement. PremierOne CAD handles dispatch for many large agencies: calls for service, units and incident timelines. The problem it solves here is not storage but retrieval, because a recording with no incident number attached is found only by someone who remembers the date.

How it connects

Incident data would come across from PremierOne 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, which is the mechanism that lets an incident number survive across the boundary rather than living in a spreadsheet beside the evidence.

Matching would be by time and unit. A body camera recording, an in-car video or a call recording carries its own start time and the device or officer it came from, and the incident timeline carries the same two facts, so the correlation is made on ingest rather than by hand afterwards. Where the match is ambiguous, because two units were on scene within the same minute, an engagement would settle whether the rule is to attach to both or to hold the item for review.

PremierOne would stay the system of record for the incident. Nothing about dispatch changes, no dispatcher does anything differently, and the platform writes nothing back unless a specific step is scoped to. A workflow could then act on the correlated record: assembling what relates to one call, or flagging a recording that arrived with no matching incident at all, which is usually the more interesting finding.

What you can do together

• Find every recording attached to a call for service by its incident number, rather than by asking who was working that shift.
• Have the incident number, unit and location arrive as attributes on ingest, so the link is part of the evidence record rather than a note.
• Run a workflow that assembles the media for one call when a disclosure request or a review needs it.
• Surface recordings that matched no incident, which is where missing paperwork and misconfigured devices show up.

A scenario

1. ScopingThe engagement would agree which incident fields come across, how time and unit are matched, and what happens when a match is ambiguous.
2. SetupThe connection would be configured once against PremierOne's API, with the attribute mapping for incident number, unit and location.
3. End of shiftRecordings ingest and each is correlated to the call it belongs to, the incident number landing as an attribute under the library's access control and retention.
4. A week laterA supervisor searches the incident number and gets every recording from every unit on that call, without knowing which officer had which device.
5. A monthly checkA workflow lists recordings with no matching incident, and two devices with a clock drift are found rather than discovered during a disclosure request.

What stays where

Products and solutions

• Nexus and AI Intelligence Hub
• Digital Evidence Management

Next step

See it on your own Motorola Solutions instance. We will show the connection made, the data moving and the output, then size it for your deployment.

Request a demonstration →  or write to sales@vidizmo.ai

sales@vidizmo.ai  ·  vidizmo.ai/integrations/catalog/motorola-solutions