Integrated access control: connecting daily operations across sites

A visitor receives approval, arrives at reception and needs access to a specific area. A delivery is waiting for its recipient to be identified. A gate malfunctions, prompting the team to review camera footage. These situations involve different resources, but they belong to the same operation.

digital brings together a web platform and mobile app for managing visitors, users, doors, gates, cameras, deliveries and incidents, with integrations, custom branding and multi-site management. Turning that scope into a consistent operation requires a clear relationship between people, devices, permissions and records. Specific features and infrastructure compatibility should be confirmed for each project.

1. Integration starts with an operational model

Bringing screens together is not enough. Start by establishing a shared structure: which sites exist, which areas belong to each site, which devices serve those areas and who can perform each action.

• Person: a user, visitor, contractor or person responsible for approving access.
• Site and area: the physical context associated with a permission or event.
• Device: a controller, reader, door, gate or camera involved in the operation.
• Event: a record of a request, state change, authorization or activity.

This structure helps prevent ambiguity, such as assigning an incident to the wrong door or leaving access active at a site someone no longer visits. It also separates registration from authorization: having a record in the system should not automatically grant access.

2. Visitor access needs an authorization lifecycle

Visitor registration should be designed as a workflow with a beginning, a validity period and an end—not simply a list of names. When defining that workflow, consider:

1. Request: who can invite a visitor and to which site.
2. Approval: who authorizes the visit and when additional review is required.
3. Validity: the permitted period, areas and conditions of use.
4. Arrival: how staff verify authorization when the visitor arrives.
5. Closure: how permission expires, is canceled or is revoked.

The identification method depends on available capabilities and the risk assessment. Whatever credential is selected, the project should address unauthorized sharing, use outside permitted hours and revocation. Changes to a visitor's schedule need a corresponding operational procedure.

3. Doors, gates and cameras serve different purposes

An unlock command does not prove someone entered

An interface may request that an entrance be unlocked, but that does not prove the equipment carried out the command or that someone passed through. Distinguish the request, transmission, controller acknowledgment, physical state and detected passage, where suitable sensors are installed.

During technical evaluation, check which states each device actually reports. Otherwise, the history may present an attempted activation as a completed access event.

Video adds context; it does not replace authorization

Associating a camera with an area can support event review. However, live viewing, recording playback and linking footage to event history are separate capabilities that depend on the integration and available permissions.

Synchronized clocks and correct time-zone handling make it easier to compare records. Without them, timestamp differences can make the relevant footage difficult to locate.

Management software does not replace physical safety mechanisms. Sensors, interlocks, emergency procedures and safe-egress requirements should be assessed by the professionals responsible for the installation.

4. Deliveries and incidents need their own workflows

A delivery should not be treated as an access authorization. Logging a package, notifying its recipient and confirming collection are separate steps from allowing the courier to enter.

The workflow should define which information is necessary, who can view the record and how completion is documented. Refused deliveries, unavailable recipients and third-party collection also need defined procedures, without unnecessary data collection.

An incident, meanwhile, needs enough context for effective follow-up:

• Classification: the type of event and its priority under internal criteria.
• Ownership: the team or person responsible for handling it.
• History: actions taken, timestamps and supporting evidence that staff are authorized to access.
• Closure: the outcome, outstanding items and reason for closing the case.

Where supported, linking an incident to an access event, delivery or device helps preserve context without copying information into multiple records.

5. Multi-site management requires clear boundaries

Organizations operating across several sites need to balance central standards with local autonomy. A corporate manager may need a consolidated view, while an individual site's team should see only what falls within its responsibilities.

A permission matrix should combine action, resource and scope. Viewing visitors at one site is different from changing permissions across all sites. Access to a camera feed should not automatically imply permission to export footage or operate a gate.

• Define which settings are organization-wide and which may vary by site.
• Separate administration, day-to-day operations and audit review.
• Review permissions when people transfer, leave or change roles.
• Assess how the system limits visibility between sites and, where relevant, between organizations.

The selected site should be clearly visible in both the web platform and the app. A consistent interface matters, but it does not replace access restrictions enforced by the system.

6. Evaluate integrations beyond the initial connection

Connecting two systems is only the first test. An integration needs clear ownership and predictable behavior during updates, outages and data discrepancies.

• Compatibility: confirm supported models, versions, licenses and functions.
• Source of truth: establish which system takes precedence for users, permissions and states.
• Authentication: assess integration credentials, privileges and renewal procedures.
• Repeated events: check how retries and duplicates are handled, especially for commands that activate physical devices.
• Traceability: determine how errors are identified, records are correlated and the appropriate support owner is contacted.

APIs, webhooks and connectors are possible mechanisms, not guarantees of compatibility. Validation should cover the actual software version and equipment that will be used in production.

7. Plan for outages from the start

Internet, power and communication failures can affect components differently. Do not assume that everything will keep working—or that everything will become unavailable.

The continuity plan should clarify which decisions require a connection, whether authorizations are stored locally and how revoked permissions are handled during an outage. It should also define approved manual procedures and who is responsible for carrying them out.

After service is restored, assess how records are reconciled and gaps are identified. Pending physical commands require particular care: an old request should not execute automatically without an explicit validity rule.

8. Custom branding should improve usability

Branding connects the system to the organization, but customization should go beyond adding a logo. Site names, guidance, error messages and the presentation of actions should help each user understand what they are doing.

Define the customization scope for both web and mobile. If a separately branded app will be published, also confirm responsibility for distribution, updates and support. A consistent brand experience should reinforce operational clarity.

9. Build privacy and accountability into the design

Visitor details, images and access histories may contain personal data. The project should identify processing purposes, responsibilities, applicable legal requirements and retention criteria. For operations subject to Brazil's LGPD, this includes assessing the obligations under that law.

Data minimization, restricted viewing and controlled exports are operational design decisions. Depending on available capabilities, the audit history should make it possible to establish who performed an action, at which site and when. Access to that history also needs to be controlled.

10. Roll out in stages and measure the process

A clearly scoped pilot helps test rules before extending them. Select a site and a representative set of scenarios: an approved visit, denied access, a cancellation, a delivery, a communication failure and an incident response.

Set acceptance criteria before testing. Evaluation can track processing time, expired authorizations that remain usable, integration failures, records lacking context and incident resolution time. These indicators need consistent definitions to support comparisons across sites.

Expansion should reflect pilot findings, staff training and each site's infrastructure, rather than simply copying settings from one location to another.

Connect technology with daily operations through digital

Managing access and activity across multiple sites means aligning software, devices and responsibilities. Start by understanding actual workflows and deciding what needs to be integrated, authorized and recorded.

Talk to digital about your operation. Share the sites, equipment and processes that need to work together to assess compatibility, priorities and an implementation scope suited to your project.