Configure and verify access schedules

Define the intended access window

An access schedule describes when an access rule should apply. For a Lexoh site, start with the intended audience, entrance or zone, calendar dates, days of the week and daily hours. Confirm how the schedule is associated with the access rule in your installed version.

A schedule is one part of an access decision. A person may also need a valid credential, an active account or another configured authorization. An open time window alone does not establish permission to enter. Pricing is a separate rule: free access charges do not necessarily mean unrestricted entry.

This guide provides a configuration and verification method. Exact field labels, boundary handling and rule combinations must be checked in the deployed version; the examples below describe explicit test policies rather than verified software behavior.

Review existing schedules and assignments

An active-day count describes days with configured periods; it does not establish their duration. Seven configured days could each contain only a two-hour window. Likewise, five days does not identify Monday through Friday unless those specific days are selected. Read the actual periods.

1. Select the correct site or organization. Record the schedule name and identifier before editing.
2. Inspect validity dates, daily periods, holiday settings and the time zone used to evaluate the rule. Distinguish the displayed time from any stored timestamp.
3. Find the entrances, zones, groups or access rules associated with the schedule. Check whether another schedule also applies to the same person and entrance.
4. Identify upcoming exceptions and the responsible administrator. Keep a record of the current settings and affected assignments.

Prepare a schedule before activation

1. Name the schedule by audience, location and purpose, such as “Visitor entrance — weekday daytime”. Keep personal information out of the name.
2. Write the intended access policy, including opening and closing boundaries, eligible people and permitted entrances.
3. Set the validity period, weekly hours and holiday treatment using the controls supported by your installation.
4. Review the schedule’s assignments and how matching or conflicting rules are resolved. Do not infer precedence from a display order or an unverified priority number.
5. Save through the authorized workflow, then verify when the change becomes effective and which devices or services have received it. Saving a form alone is not proof of successful activation.

Separate audience from permission

Users, customers and guests

If these categories appear in your configuration, confirm which records belong to each one. A user category is not proof of administrative permission, paid status or a valid access credential. Test a representative authorized record and an unauthorized record.

Staff and temporary access

Give each group the hours required for its approved duties. Do not grant every staff member continuous access merely because the record is classified as a user. Give contractors a defined validity period and review the end of their assignment.

Multiple rules

Check what happens when the same credential matches more than one schedule or access rule. An empty period in one schedule does not, by itself, prove that another rule cannot authorize entry. Verify both expected admission and expected refusal.

Set dates and the time zone explicitly

A validity period limits the dates on which weekly hours can apply. Confirm whether start and end values represent whole dates or exact timestamps, and whether each boundary is included. Test the first and last allowed moments, not just a day in the middle.

For a continuing schedule, use the supported open-ended configuration if one exists. Do not invent distant dates as a substitute without checking the system’s requirements. For temporary access, record a deliberate end date and a review owner.

Use the site’s intended time zone consistently. Where seasonal clock changes apply, test a repeated or skipped local time with the administrator. Include the date, local time and UTC offset in a test record when needed to distinguish two occurrences of the same clock time.

Verify how holidays interact with daily hours

Calendar selection

Confirm which holiday calendar or named dates the schedule references, including the correct year and observed closure dates. Review how later calendar edits affect linked schedules; do not assume dates renew automatically.

Exclude holidays

If a holiday-exclusion option is available, test a selected holiday that otherwise falls inside a normal weekly period. Also test an ordinary day with the same hours. Check other matching rules before concluding that entry is refused.

Holiday-only access

Confirm whether a holiday-only option also applies daily time periods or uses a different time window. Do not assume it permits the entire day or ignores weekly hours. Test before opening, inside the permitted window and at closing on both a holiday and an ordinary day.

Check split shifts, midnight and full-day access

Several periods in one day

For a split shift, write each permitted interval and the intended gap. Check whether the interface accepts, merges or rejects overlapping periods. Test during the gap as well as during each shift.

An interval across midnight

For a Friday 22:00 to Saturday 02:00 policy, confirm whether the software accepts an overnight interval or requires separate daily periods. Check which date controls holiday and validity conditions on the Saturday portion. Never assume that an end time earlier than the start is interpreted as the following day.

Continuous access

Use the supported full-day setting or documented interval convention. A displayed 00:00–23:59 range does not establish coverage of the entire final minute. Verify end-boundary precision and the handover to the next day.

No configured period

Confirm what a blank day means in the installed version and how other rules affect the result. A blank field should not be used as a security assumption.

Use explicit boundary tests

Illustrative policy: one eligible visitor may enter one specified entrance on an ordinary weekday from 08:00 inclusive until 18:00 exclusive. Selected holidays are excluded. No other rule grants entry. The following expectations follow from this invented policy, not from a tested Lexoh installation.

Overnight test set

For a separate Friday 22:00 inclusive to Saturday 02:00 exclusive policy, test Friday 21:59, Friday 22:00, Saturday 01:59 and Saturday 02:00. The expected sequence is refuse, allow, allow, refuse. Repeat with a validity end or selected holiday at midnight to verify the intended exception.

Record the actual outcome

For each supported test, retain the schedule and access-rule identifiers, credential test reference, entrance, exact time and observed decision. Investigate differences between the written policy and the installed behavior before activation.

Test, activate and maintain the schedule

Do not change a live access rule solely to try an example. Arrange any operational test with the site administrator and follow the site’s established equipment and access procedures.

1. Run approved tests for eligible and ineligible records, opening and closing boundaries, blank days, holiday exceptions, overlapping rules and overnight periods. Use the supported test environment or an agreed site procedure.
2. Verify configuration receipt and the access event recorded by the relevant system. Keep the access decision separate from the physical equipment response when diagnosing a failure.
3. Confirm the responsible administrator, activation time and recovery procedure. Keep the previous configuration available.
4. Review the first approved operational results and record the outcome. Recheck schedules when staffing, opening hours, holidays, assignments or time-zone settings change.