
Test holiday door schedules before the building closes
Review holiday door states, credential permissions, exceptions, time zones, and reopening behavior before an unattended closure.
Quick answer: Review a holiday as a complete change in building operation: public door state, individual credential permissions, approved special visits, and the next reopening. Test the effective settings for each affected site before staff leave. A holiday entry in one calendar does not prove that every door schedule and access policy follows it.
A closed sign does not change the controller's weekly schedule. If an office normally unlocks its reception entrance on a weekday morning, that opening can behave the same way during a holiday unless the applicable configuration has been changed correctly.
The reverse mistake is also disruptive: an exception remains active after the closure and blocks the people responsible for reopening. A useful holiday review therefore includes both transitions. The building should enter the intended closure state and return to its approved operating pattern without relying on someone remembering an undocumented override.
Start with the site's actual closure decision
Confirm the dates and operating expectations for each location. A company-wide holiday does not necessarily mean every branch, tenant, service area, or support function closes. Ask the responsible local team which entrances remain in use and whether any part of the property follows a different schedule.
Distinguish public access from authorized staff entry. The business may close reception while allowing a small approved group to perform maintenance or respond to an issue. Those requirements should be expressed separately so the implementation does not accidentally make every employee a holiday exception.
For a hypothetical regional office, the customer entrance may remain closed while an approved facilities worker uses a side entrance during a scheduled visit. The closure review should specify that route and interval rather than simply label the whole site open or closed.
Use the door survey checklist to confirm which physical openings the system controls. A calendar change cannot govern an entrance outside the electronic system, and a controller setting does not establish the condition of unrelated mechanical locks or tenant doors.
Review the door's scheduled state
Identify each recurring schedule that can leave an affected door unlocked. Confirm where holiday exceptions are configured and which doors actually use that schedule. A correctly named holiday calendar is useful only if the relevant opening is associated with it.
Ubiquiti's door-unlock documentation includes holiday exceptions within recurring unlock configuration. It also describes first-person-in and one-time unlock functions. Those are separate behaviors that should be inspected in the installed system rather than assumed from a calendar label.
Look for manual or temporary states that could affect the result. A door left in an always-unlocked mode for an earlier event needs particular attention; a holiday change elsewhere should not be presumed to cancel every override. Confirm the actual precedence and supported controls for the selected platform.
Have the administrator show the effective state over the whole closure interval. The review should answer when the door stops following its ordinary public opening pattern and what causes normal operation to resume. Avoid interpreting a screenshot of one setting as proof of the full sequence.
Check credential permissions independently
A door can remain locked while authorized credentials still open it. Decide which people should retain that ability during the closure, through which doors, and for what purpose. This is a different decision from whether the entrance opens freely during business hours.
UniFi's policy documentation describes holiday-specific access times and states that multiple policies combine allowed periods. A restrictive holiday policy therefore needs to be reviewed alongside other assignments that may still permit entry.
Include regular employees, managers, facilities staff, recurring visitors, and temporary workers as appropriate to the site. Their permissions may be administered through different workflows. Do not assume that a calendar attached to the main employee policy also changes every visitor or contractor authorization.
Choose representative test identities for the intended allowed and denied cases. The objective is not to remove all holiday entry automatically; it is to prove that the people who retain access have a current approved reason, and that the broader closure decision is actually reflected in the system.
Resolve special visits before the last working day
Cleaning, deliveries, equipment service, and scheduled maintenance may continue during a public closure. Collect those requests early enough to decide whether they should proceed, be rescheduled, or use an attended entry process. A surprise call to the person who has already left town is a poor access plan.
Approve the minimum practical route and interval for each visit. Confirm who meets or supports the visitor, how identity is checked, and what happens if the appointment changes. Keep the permissions tied to the actual visit rather than leaving a general holiday-service group active indefinitely.
For a hypothetical maintenance appointment, the worker may need access to a particular entrance and equipment room for part of one day. That does not justify opening the public lobby all morning or giving the vendor access throughout the entire holiday period.
Make the escalation path clear to the local staff handling calls. If a visit was not approved, they should know who can authorize it and which process to use. Remote unlocking should remain an intentional decision with appropriate verification, not an automatic response to someone claiming to be expected.
Test the boundaries without creating a live surprise
Use an approved test method and a controlled window with the responsible administrator. Do not move a production controller's clock or broadly alter live schedules merely to see what happens. The test should establish the relevant behavior without disrupting other openings or obscuring meaningful event times.
Ask the installer or administrator how the platform supports previewing, simulating, or safely exercising schedule changes. Where a temporary test schedule is appropriate, define its scope and restoration step. Keep any unavailable test condition visible rather than claiming that it was proven.
Review these boundary cases:
- The last ordinary public opening period before the closure.
- The start and end of the holiday exception at the site's time basis.
- An approved special visitor and an ordinary employee credential.
- Any overlapping rule or manual unlock condition.
- The first reopening period after the holiday.
- A site in another time zone using a similar calendar name.
Observe the physical opening as well as the software state where the test permits. A controller can issue the intended command while a door remains ajar or fails to latch. Physical closing and required exit behavior need their own appropriate checks; a schedule is not a substitute for a functioning opening.
Arrange the final closure and the next reopening
Identify the person responsible for the site's normal closing procedure. That process may include checking entrances, confirming scheduled exceptions, and reporting an unresolved physical problem. It should be appropriate to the property and should not depend solely on a remote dashboard showing a favorable status.
Keep required egress and emergency functions within the approved door design. A holiday does not justify blocking exits, adding improvised restraints, or disabling safety functions to make the building appear more secure. Any change to the opening's safety behavior belongs with the qualified professionals and responsible authorities for that site.
Plan the first morning back with equal care. Confirm who arrives first, which entrance they use, whether their credentials are active, and what condition allows the public door to open. If first-person-in behavior is part of the design, test the actual supported method rather than assuming any remote command satisfies it.
Provide a concise fallback procedure for the person reopening. It should name the appropriate support contact and authorized actions if the expected behavior fails. Avoid requiring that person to improvise administrator changes or share an unrestricted credential with waiting staff.
Maintain the calendar through organizational changes
A holiday configuration can become stale when a branch changes hours, a tenant moves, or an administrator clones an older schedule. Review the calendar when those operational changes occur, not only once at the beginning of a year. The current business decision should determine the applicable dates and exceptions.
Keep schedule names clear enough to reveal their scope. A label such as company holidays may hide differences among locations or departments. The actual settings and door assignments remain authoritative, but readable names make it easier to notice when a shared calendar is being applied too broadly.
After the closure, check that temporary exceptions ended and the intended regular operation resumed. Investigate unexpected entries or denials using the appropriate event records and local context. The purpose is to improve the next closure, not to assume that every unusual event proves wrongdoing.
Use recurring trouble as purchasing feedback. If administrators cannot confidently see which doors and users an exception affects, require a better demonstration during the next system review. Calendar usability is part of operating an access system, alongside reader hardware, credential choices, and installation quality.
The takeaway
Holiday access is a coordinated change to door state, individual permissions, special visits, and reopening. Updating one calendar is only sufficient when the business has verified how that calendar affects the complete arrangement.
Review each affected site before the closure, test meaningful boundary cases, and leave the people closing and reopening with a clear procedure. That produces a more dependable result than relying on a last-minute manual override and a reminder to undo it later.
Make closure schedules part of your access plan
BlueHouse Telecom helps businesses scope electronic access control nationwide, including door schedules, credential permissions, and operational acceptance checks.
FAQ
Does adding a holiday automatically close every door? No. Verify which door-state schedules and user permissions reference the exception, and check any overlapping or manual controls. The effective configuration matters more than the calendar's name.
Can employees still badge in when the public entrance is closed? They may be able to if their permissions allow it. Decide which roles should retain holiday access, then test those permissions separately from the door's sustained unlock schedule.
Should I change the controller's clock to test a holiday? Use the platform's supported test approach with the responsible administrator. Changing a production clock can affect other functions and records; a controlled test should avoid creating those unintended effects.
What should be checked after the holiday? Confirm temporary exceptions ended, normal schedules resumed, and the approved opening procedure worked. Review unexplained access events or denials with the appropriate local context and update the next closure plan if needed.
