Integrated Access, Video and Intrusion Workflows
An integrated security system should reduce response time and improve evidence without creating hidden dependencies. 24/7 Security maps access, video, intrusion and intercom events to the people, screens, notifications and procedures that must act on them, then verifies product and version support before configuration.
Select the complete system, not one headline feature
Match devices, software, licensing, infrastructure, retention, integrations and support to the operating requirement before finalizing the design.
Operational use cases and integration boundaries
Interview security, facilities, IT and compliance teams about door forced, door held, denied access, intrusion alarm, intercom call, analytic, duress and visitor events. For each, document who receives it, what context is needed, the expected decision and the required record.
Prioritize a small set of high-value workflows. Automatic camera call-up, bookmark creation or credential disablement can help, but only when false events, latency, permissions and after-hours ownership are understood.
Write each workflow as a sentence a shift supervisor would recognize: this event, this recipient, this decision, this record. A workflow nobody on the floor can state that plainly is a candidate for later producing alarms with no owner at two in the morning, so hold it back from the first phase.
- Trigger/context/action matrix
- Named operator and escalation
- System of record
- Failure and fallback behavior
Identity, event and network architecture
Confirm exact platform editions, licenses, firmware, APIs and supported connectors. ONVIF profiles standardize selected functions, not every vendor feature. Map authoritative user, credential, schedule, door, camera and site identifiers and prevent duplicate records from drifting.
Place servers and devices on approved networks with DNS, NTP, certificates, firewall rules and least-privilege service accounts. Record cloud dependencies, outbound connectivity and data locations. Protect integration keys and avoid shared administrator credentials.
Integration capability can sit behind a license tier or a separate connector, so price the edition each platform actually needs rather than the base product. Verify that the quoted connector version supports the firmware the doors and cameras run today, since an upgrade forced on one side can reopen the whole schedule.
- Supported versions and licenses
- Identity and object mapping
- DNS/NTP/certificates
- Least-privilege service accounts
| Stage | Question | Acceptance |
|---|---|---|
| Trigger | What reliable event starts it? | Event arrives once and on time |
| Context | What video/identity is shown? | Correct synchronized information |
| Action | Who decides or automates? | Authorized, logged response |
| Failure | What if a system is offline? | Safe fallback and alert |
Configuration and scenario commissioning
Stage mappings by site, door, camera and event. Define debounce, severity, notification, escalation, video pre/post-roll and audit behavior. Use a change plan so a bad mapping cannot generate uncontrolled alarms or unlock commands.
Test normal, denied, forced, held, alarm, offline and recovery scenarios. Verify video time alignment, camera selection, user permissions, evidence export and operator acknowledgement. Confirm the source system still operates safely if the integration stops.
The integration’s service account needs its own credential and only the rights its mappings use, never an operator’s or an engineer’s login. Keep an exported copy of the mapping set before each change so a bad rule can be rolled back without rebuilding it, and read release notes on both platforms before either is updated.
- Controlled event mappings
- Severity and notification
- Normal and failure tests
- Evidence and time alignment
Governance, upgrades and incident evidence
Document connector and platform versions, licenses, service accounts, mappings, certificates, ports, time source, tests and exception ownership. Store sensitive architecture and credentials in the client repository.
Review integrations before upgrades and after certificate, firewall, identity or camera changes. Operations should own health alerts, account rotation, audit review, evidence retention and a manual fallback procedure.
Prove the failure case as well as the working one: take the connector offline and confirm doors, alarms and recording carry on by themselves, then show that an exported clip still carries a timestamp an investigator can defend. Closeout records versions, mappings, accounts and the manual fallback, with an owner beside each exception.
- Version and certificate register
- Health monitoring owner
- Upgrade regression tests
- Manual response fallback
How we plan and deliver the work
The final design depends on site conditions, existing systems, client policies and the selected manufacturer or platform.
Map the events
List the alarms, door events and camera views that must reach a person, and name who acts on each.
Confirm version support
Check that each platform, license level and firmware release actually supports the links the workflow depends on.
Build the links
Configure event bindings, user directories and network routes between the access, video and intrusion systems in a staging window.
Run the scenarios
Walk forced door, duress and after-hours alarms end to end, then record what each operator saw and did.
Information to gather before design
Integration fails on details that live between systems, so platform versions, account ownership and response procedures matter more than the feature list on any single product.
- Software versions and license levels installed
- Who receives alarms on each shift
- Network segments carrying security traffic
- Directory that owns user accounts
- Events that must pull up video
Frequently asked questions
These are common planning questions. A site-specific answer should be confirmed during discovery and design.
Does ONVIF guarantee every camera and access feature works together?
No. Profiles define selected interoperable functions; verify conformant products, profiles and exact features.
Should one platform own all user data?
Define an authoritative system and synchronization rules to prevent duplicates and inconsistent permissions.
Can an integration unlock doors automatically?
Only after risk, code, authorization, failure behavior and audit requirements are explicitly approved.
What should be retested after an upgrade?
Event receipt, mappings, video, identity, actions, permissions, evidence and failure recovery.
Manufacturer software, firmware and technical files remain on the manufacturer’s official website. We do not mirror firmware files locally.
Connect your access, video and intrusion events
Describe the systems you run today with their software versions, the alarms that currently go unanswered, and the response steps you want handled automatically, so the integration can be scoped realistically.