Skip to main content
2026

EyeQ Camera Provisioning

20,000 cameras. 7 platforms. One question: where does truth live?

EyeQ Camera Provisioning preview
01

The Problem

20,000 cameras. Seven different platforms. One question nobody could answer cleanly: "Which cameras are installed at this site?"

EyeQ provision agents moved between systems constantly. IPVM for camera specs. SimPRO for project management. EyeQ Cloud VMS for device configuration. Immix for monitoring. PRTG for network health. InnoVi for analytics setup. Excel templates for everything the systems didn't track.

Each platform owned part of the truth. None agreed.

A camera had an IP address in three places with three different values. Site addresses lived in four systems. When provisioning failed, troubleshooting meant checking all seven platforms in sequence, hoping to find where the disconnect happened.

New agents took months to learn which system held which attribute. Experienced agents kept personal notes mapping system relationships—their own shadow documentation of "check here for this, check there for that."

The equipment was sophisticated. The information architecture was chaos.

02

What We Heard

This was a mapping and documentation project, so we worked with internal provision teams and project managers rather than end customers.

New provision agents told us training took months just to learn which system held which attribute.

Experienced agents kept personal notes—shadow documentation of "check here for this, check there for that." This tribal knowledge was the only way to navigate seven platforms.

When troubleshooting, the pattern was always: check all seven systems in sequence, hoping to find where the disconnect happened.

One agent said: "A camera IP address can be wrong in three places. Which one do I trust?" Nobody had a good answer.

03

The Method

We mapped what exists across the entire provisioning workflow.

10 objects emerged. And one of them—CAMERA—had 52 attributes. Fifty-two. Firmware version. Network configuration. Analytics settings. Physical placement. Recording schedule. Motion detection zones. Integration status across multiple platforms.

52 attributes on one object is a smell. Either you're conflating concepts or the domain is genuinely that complex. In industrial IoT systems, it's usually both. But here's the thing: we didn't try to fix that complexity. We documented it.

CAMERA — the core entity everyone cares about, scattered across seven systems SITE — customer locations with monitoring requirements and security protocols CUSTOMER — organizations owning multiple sites SERVER — VMS instances managing camera feeds PROTOCOL SHEET — authorized contacts and security procedures (because you can't just call anyone when an alarm triggers) USER — provision agents, project managers, technical support, each with different permission needs

The relationships revealed the system-of-record problems:

• CAMERA.IP_ADDRESS — authoritative in EyeQ Cloud VMS, but referenced in Immix, InnoVi, and PRTG • SITE.ADDRESS — created in SimPRO, synced to VMS, used by dispatch in Zoho • CAMERA.ANALYTICS_CONFIG — set in InnoVi but triggered by rules in Immix

We documented which platform was system of record vs. system of reference for every attribute. Not to build new software. To make the implicit explicit.

04

The Solution

Object map documenting the complete provisioning workflow across 10 objects and seven platforms.

52 attributes on CAMERA alone, revealing the genuine complexity of industrial IoT provisioning.

System-of-record designations for every attribute—clarifying which platform is authoritative and which are references. CAMERA.IP_ADDRESS is authoritative in VMS, even though it appears in four other systems.

Relationship mapping showing how data flows between IPVM, SimPRO, EyeQ Cloud VMS, Immix, PRTG, InnoVi, and Excel templates.

Documentation replacing tribal knowledge—new agents can ramp faster because the system relationships are explicit instead of living in experienced agents' heads.

Troubleshooting paths clarified: instead of checking all seven platforms in sequence, agents now know where to look first based on which attribute is failing.

05

What Changed

Object map delivered. 10 objects. 52 attributes on CAMERA alone. System of record documented for each attribute across seven platforms.

No software built. No integration code written.

But training time for new provision agents dropped. Troubleshooting paths became clearer. Conversations shifted from "check everywhere" to "IP address is authoritative in VMS, go there first."

The map itself became the product.

This echoes TBOT and Driftwood Alchemy. Sometimes the deliverable is clarity. The next person who provisions a camera will never know you made their job easier, and that's fine.

06

Lessons for Others

First: IoT complexity isn't in the devices. It's in the relationships between devices, platforms, and people. A camera is simple. A camera connected to seven systems with different data models is not.

Second: System of record vs. system of reference matters. Every attribute needs an authoritative source or you get three truths. This is probably the most transferable insight from the work—applies to any multi-system environment.

Third: 52 attributes on one object is a smell. Either you're conflating concepts or the domain is genuinely that complex. In industrial systems, it's usually both. Don't judge the number. Understand why it's there.

Fourth: Sometimes the deliverable is clarity, not code. Documentation that lives in people's heads isn't documentation. Making it explicit has value even if nothing else changes.

Fifth: Tribal knowledge is a liability. When experienced agents keep personal notes to navigate your systems, your information architecture has failed. Those shadow docs should be a signal, not a workaround.

07

Broader Implications

Enterprise IoT systems are almost always multi-platform nightmares. Devices, VMS, analytics, monitoring, project management, billing—each best-of-breed in their category, none designed to work together.

The common response is "build integration middleware" or "buy a platform that does everything." Both are expensive bets that fail if you don't understand the domain first.

Mapping system-of-record relationships is unglamorous work. No flashy UI. No launch announcement. But it's often the highest-value thing you can do. It de-risks integration decisions, accelerates troubleshooting, and turns tribal knowledge into team knowledge.

As IoT deployments scale into tens of thousands of devices, the teams that invest in understanding their information architecture will outpace the teams that just keep adding platforms.

The End

Twenty thousand cameras. Seven platforms. One map.

The cameras are still in the same systems. The platforms still don't perfectly agree. Integration middleware wasn't built.

But when an agent troubleshoots a provisioning failure now, they know where to look. When a new hire asks "where does this live?" the answer exists.

We didn't fix the chaos. We gave it a shape.

Sometimes that's enough.