Integrated Security System Design: Event Workflows Across CCTV, Access, Alarms and Intercoms
Essential Security Supplies
Integrated security system design should start with an event workflow: what happens, which system detects it, what information reaches the operator and what action is permitted. Connecting CCTV, access control, alarms and intercoms does not automatically create a useful response. For NZ commercial projects, define a small set of measurable workflows, verify their exact interfaces and test both normal operation and failure. A shared dashboard is valuable only when it supports the decisions the site actually needs.

Describe the operator's task before selecting integrations
Choose a real event such as a forced door, an unanswered intercom call or an intrusion alarm in a closed area. Identify the initiating system, location, priority, required evidence and intended operator. Write the desired response in plain language. Avoid beginning with a vague requirement that every system must integrate with every other system.
Distinguish notification from control. Displaying a camera beside an access event is different from remotely unlocking a door, disarming an area or triggering an output. Each control action needs clear authority, confirmation and logging. Keep safety-related functions governed by their approved design and responsible specialists; a convenience workflow must not become an undocumented override.

Build a cause-and-effect matrix
| Event | Information required | Permitted response | Failure question |
|---|---|---|---|
| Forced door | Door identity, event time and relevant camera | Review and escalate under site procedure | What if video is unavailable? |
| Intercom call | Correct entrance, audio and authorised recipient | Communicate and release only if approved | What happens when unanswered? |
| Intrusion alarm | Zone, armed state and available verification | Follow the agreed response plan | What if the interface is offline? |
| Power fault | Affected supply and dependent devices | Assign service response | Is the fault still reported during outage? |
Give each workflow an identifier and link it to a requirement and acceptance test. Record the normal sequence and the conditions that should suppress or change it. For example, a held-open door during an approved delivery period may need a different response from the same event after hours. The workflow should explain that distinction without relying on operator memory.

Verify the exact integration method and limits
List model, software version, firmware, driver or plugin, licence and supported function for every interface. Manufacturer platform literature can show possible capabilities, but does not prove compatibility for the proposed combination. RBH's Axiom material describes video and access functions; the exact supported workflow still needs confirmation for the installed platform and integration version.
Treat protocol labels carefully. ONVIF support does not guarantee every analytic event, SIP does not establish every door-release method, and an API does not prove the application implements the needed operation. Ask for a function-level compatibility statement and test any critical uncertainty before committing the design. Identify responsibility for updates that may change interface behaviour.
For hardwired signals, define the electrical interface, supervision, normal state and event meaning. A dry contact can communicate one state but may not carry the detail needed for a rich operator workflow. Confirm whether a broken wire is distinguishable from the intended event. Do not describe an unsupervised contact as a fully monitored data integration.
Keep event names, locations and timestamps consistent
Use the same door and camera identifiers in drawings, software and response instructions. A forced-door event named rear entry is ambiguous on a site with several rear doors. Associate the correct cameras and verify the view in the installed location. Include enough context for an operator unfamiliar with the building to make the intended decision.
Synchronise time through the approved network design and verify displayed and recorded timestamps. Different clocks can make a correct video association appear wrong or complicate incident reconstruction. Record time zone and any relevant offset during testing. Do not alter preserved evidence to make timestamps appear consistent; document discrepancies and correct the operational configuration through the approved process.
Define authority, acknowledgement and escalation
Specify which roles may view video, acknowledge alarms, release doors or change configurations. Use individual accounts and the least permissions needed for the task. Protect administrative and remote access with appropriate authentication, including MFA where supported. Integration can expose more functions through one interface, so permission design deserves separate testing.
Decide whether acknowledgement means an operator has seen the event, accepted responsibility or completed the response. Those are different states. Record escalation if an event is unanswered or remains unresolved. Avoid a workflow that clears the initiating alarm merely because another application displayed a pop-up. The response record should reflect what actually happened.
Review the effect of automation on people. Automatically unlocking a door from a video analytic event is a different risk from calling up its camera for review. Require explicit design authority and suitable safeguards for control actions. Never infer that an available software rule is appropriate for every site or compliant with the building's approved arrangements.
Design for partial failure and local operation
Ask what happens if the integration server, network, recorder or cloud connection fails. Determine which local services continue and what the operator loses. A door controller may retain local permissions while video association becomes unavailable, but that behaviour must be confirmed for the exact equipment and configuration. Do not infer offline capability from a platform name.
Keep required emergency and local exit functions independent in accordance with their approved design. Define fallback procedures for unanswered intercom calls, missing video and lost event delivery. Consider event queues and reconnection behaviour: a restored interface may deliver old events that need clear timestamps and handling. Test recovery rather than assuming normal operation resumes cleanly.
Test workflows from physical event to operator result
Use a designated test credential, door or zone and an agreed test window. Create the physical event, verify the initiating record, observe the integrated display and follow the authorised response. Confirm the correct camera, location, event priority and audit record. A successful API call from a laptop does not prove that the site's installed workflow works.
Repeat with a relevant negative condition, such as an unavailable camera or disconnected integration path, using the approved procedure. Verify the fault is visible and the fallback is understood. Restore service and confirm recovery. Record exact versions, test conditions, expected result and observed result so a later update can be checked against the same sequence.
Hand over an integration register and change process
Provide the cause-and-effect matrix, interface ownership, licences, version information and support contacts. Protect credentials and configuration backups through the client's approved method. Include privacy arrangements for combined access and video records, since joining datasets can reveal more about a person's movements than either system alone.
Prioritise a few valuable, well-tested workflows over an unverified promise of complete integration. Review after software updates, changed doors, new operating hours or altered response responsibilities. A maintainable integrated system makes events clearer and actions accountable while preserving the local functions and failure behaviour the site depends on.
Equipment selection and technical references
Use these access control options as a starting point for a project specification. The pictured items are equipment candidates, not a pre-approved complete design. Confirm model, accessories, interface support and suitability before ordering.
Related installer guidance: Sip intercom integration door stations phones access control.
Primary references checked 24 October 2026: rbh-access.com technical guidance; www.ncsc.govt.nz technical guidance; www.privacy.org.nz technical guidance.
Frequently asked questions
Does one dashboard mean systems are fully integrated?
No. Verify the exact events, controls, permissions and failure behaviour required. A shared display may provide only a subset of the intended workflow.
Can ONVIF or SIP support prove every function works?
No. Confirm exact models, versions and function-level support, then test the intended event and response through the installed systems.
What should happen when an integration server fails?
The design must state which local services continue, what faults are reported and what fallback operators use. Confirm those behaviours for the selected equipment through controlled testing.
Get project specification help
Contact Essential Security Supplies with your site layout, proposed equipment and operating requirements. Ask for model-specific technical support or a trade quotation before finalising the design.