Access granted through groups and schedules attached to roles, not to individuals - that is what separates a system still accurate in year three from one that has drifted.

With a group model, a new starter is put in a group and inherits the right doors and hours in one action.

A department change moves them between groups, and the old permissions leave with the old group rather than accumulating.

Per-person, per-door administration works for twenty people and fails for two hundred, because the effort of keeping it correct exceeds the attention anyone gives it.

Look for the ability to combine a group with a time schedule and an area, and to nest or inherit groups where the organisation has structure.

Test the model in evaluation with a realistic case: a contractor needing three doors for six weeks, and a person moving department mid-month.

Door states, alarms as they happen, and immediate manual control - release, lock, and lockdown.

A graphical plan or a clear list showing which doors are secure, open, forced or held is the operator's basic tool.

Alarms need to arrive with enough context to act on: which door, what kind of event, who was involved and, where video is integrated, a picture.

Manual control matters in ordinary use too - releasing a door for a delivery is a daily task.

Lockdown is the function that must be tested rather than assumed: how quickly it can be invoked, which doors it affects, who can invoke it, and how it is reversed.

Check what lockdown does to escape routes. It must not conflict with the fire strategy, and in most jurisdictions it cannot prevent people leaving.

Directory or HR synchronisation first, then video, then the intruder alarm.

Identity synchronisation ends the leaver problem: access is removed on the same day the account is, without anyone remembering.

It also handles joiners and movers, which is where most of the ongoing administrative effort actually goes.

Video integration bookmarks recorded footage with access events, turning an hour of review into a single click - the most-used integration after identity.

Intruder alarm integration lets a credential disarm an area on entry and arm it on last-out, removing a separate keypad and a shared code.

Confirm each integration is supported for the specific versions in use, and check whether it is a separately licensed module - it usually is.

Through a visitor record with a host, an expected time and an automatic expiry on the credential issued.

The failure mode is a drawer of visitor cards handed out and never reconciled, which accumulate and stay active.

A visitor module or a well-used temporary credential process with mandatory expiry solves it.

Linking the visitor record to the credential means the audit trail shows who was holding the card, which a bare card number does not.

Pre-registration by the host saves reception time and produces an expected-arrivals list, which is also useful for evacuation.

Contractors sit between visitors and staff: access for the duration of the works, to the areas the works cover, expiring on the contract end date.

Named administrator accounts with role-based permissions, multi-factor authentication, a patching plan, and controlled remote access.

Shared logins destroy the administrative audit trail, which is exactly the record an investigation needs.

Roles should separate enrolling a person from changing door rules from deleting events. Not every administrator needs all three.

Multi-factor authentication is now a baseline for anything reachable remotely, and increasingly for local access too.

The server needs the same patching and backup discipline as any business system, and the backup needs testing rather than assuming.

Whatever route the integrator uses to connect remotely should expire, and the customer should be able to close it. A permanent vendor tunnel into the system that opens the doors outlives the project team.

Yes, and multi-site is where the platform choice matters most - the question is whether administration can be delegated without giving everyone global rights.

A central database with regional administrators who can only see and edit their own sites is the arrangement most organisations need.

Global policies - credential formats, password rules, standard access groups - should be set centrally and inherited.

Network resilience matters more across sites, so confirm the controllers keep working locally when a site loses its link.

Time zones, public holidays and local working patterns all affect schedules, and a platform that assumes one calendar becomes irritating quickly.

Data residency may constrain where the database can live, particularly for cloud deployments spanning jurisdictions.

Long enough to investigate a realistic incident, and no longer than the retention policy justifies - because access logs are personal data.

Most privacy regimes expect a written justification and a finite period for records that track individuals' movements.

Against that, incidents are frequently discovered weeks or months after the event, so a very short retention makes investigation impossible.

Sector rules sometimes set a minimum - regulated environments often require a specific period.

Archiving to a separate store with restricted access is a common compromise: the live system stays fast while the history remains available.

Whatever the period, it should be written into the system's documentation, applied automatically rather than manually, and reviewed against the local rule.