Objective
This document outlines the execution logic and conditions applied in the zonal configuration of an access control system. It explains the flow of condition checks, how "OR" logic operates, and the sequence of execution for different access criteria. The goal is to ensure the correct order of execution based on priority, alert status, and membership package validation.
Initial Execution Order
In the zonal access control configuration, conditions are evaluated in a specific sequence, as defined by the system administrator. These conditions must be assessed one by one in the order they are listed from top to bottom. The sequence is as follows:
Note: The Order of Execution also depends on order of when they are created.
See the example of configuration from Acton Park site which can be used as template. And explanation of the logic below.
- Entry Point Check: The system will first verify the entry point condition. This can involve evaluating whether the member is trying to access a valid zone.
- Alert Priority Check: If the entry point condition is met, the next condition checked will be the member's Alert Priority. This evaluates whether the member has any active alerts that could affect their access.
- Status Check: The third condition evaluated is the Status of the member, ensuring the individual is in an appropriate status to access the facility (e.g., active, not suspended).
- Site Check: Finally, the system will check whether the member is associated with the correct site for access, verifying location-specific restrictions or permissions.
Handling Failed Conditions (OR Logic)
If any of the above conditions fail, the system will move to the next set of conditions within the “OR” logic block. The evaluation will proceed sequentially from top to bottom, checking the conditions defined in the OR block. This allows flexibility in access management, as failing one condition will allow other alternatives to be evaluated.
- Example: If a member has a high-priority alert on their account and the Alert Priority condition fails, the system will proceed to evaluate the next condition within the OR block, which may be related to the Package.
Example Scenario: Member with High Priority Alert
Consider the following scenario to understand the process:
- A member attempts to access the facility.
- The system first checks the Entry Point condition. If valid, the system continues to check the next condition in line.
- The system then checks for any Active High Priority Alerts on the member’s account. If a high-priority alert is present, this condition will fail (assuming the access policy is designed to block access with high-priority alerts).
As the Alert Priority condition fails, the system will now proceed to the next block of conditions defined by the OR logic. In this case, the next condition to be evaluated is related to the Package.
Package Validation
Once the system moves to the “OR” condition related to Package, the next step will be to check if the member has a valid Package. This can involve verifying whether the member is subscribed to an access package that allows entry to the facility.
- If the member does not have the correct package, access will be blocked.
- If the member has a valid package, access may be granted, but other conditions (such as Status and Site) will still need to be verified.
Further Logic (No Rechecking of Previous Conditions)
After the system checks the Package, it will not revisit previous conditions, such as the Alert Priority or Status, unless a new block of logic is added to the evaluation process. This is an important point to note for system configuration. Once the flow shifts due to the failure of one condition (e.g., Alert Priority), the system will not revisit the previous checks in that particular block.
Therefore, if Package validation fails, the system will not recheck the Alert Priority condition, and access will be denied at that point.
Adding Additional Conditions for Execution Blocks
If required, additional conditions can be added to the flow to ensure more detailed control over the access process. These new conditions should follow the same "top-to-bottom" logic, similar to the initial evaluation order.
For example, a new block of conditions might follow this sequence:
- Package Check (to confirm if the member is eligible for the desired package)
- Entry Point Check (to confirm the member is trying to access a valid zone)
- High Priority Alert Check (to ensure no critical alerts block access)
- Package OK Status Check (to confirm the package status is valid for access)
This sequence ensures a comprehensive evaluation and minimizes potential issues with access control logic.
Role of the DL HO Administrator
The DL HO Administrator plays a critical role in deciding the order of execution for the various conditions. The administrator will configure the system based on the specific needs and priorities of the organization. The admin must determine:
- Which conditions are most important for granting access.
- The relative priority of different checks (such as Package validation, Alert Priority, etc.).
- The exact order of conditions to balance security and convenience.
This level of customization ensures that the system operates in a way that aligns with the organization’s security policies and access requirements.
IMPORTANT NOTE
While editing the rules if new rules are being created, the old rules need to be DEACTIVATED and NOT DELETED. If the rules are deleted it will not be changed in the front desk database access zone rules table and all the previous rules will still be effective and can let members enter even if rules are failed.
Summary of Execution Flow
To summarize the execution flow of access control logic:
- Conditions are checked sequentially, starting from the Entry Point to the Site.
- If any condition fails, the system moves to the next condition defined in the OR logic block.
- Once the system evaluates a failed condition and shifts to the next block, it will not revisit previously failed conditions.
- Additional conditions can be added to ensure a thorough evaluation of the access request.
- The DL HO Administrator is responsible for defining and customizing the sequence of condition checks to align with organizational needs.
Access Zone Configuration
The Access Zone settings control entry and re-entry permissions for members, ensuring efficient access management. The following parameters define the behaviour of the access system:
- Grace Period: Determines the time (in minutes) a member is allowed to re-enter the Access Zone without a new entry being recorded. In this configuration, the grace period is set to 0 minutes, meaning every entry is immediately logged as a new access event.
- Passback Period: Defines the duration (in minutes) after the grace period during which a member is restricted from re-entering the Access Zone. Currently, it is set to 1 minute, preventing immediate consecutive entries.
- Monitoring Mode: The system operates in Semi Monitored mode, meaning only access attempts with issues or alerts will require user intervention. This provides a balanced approach between automated access control and manual oversight.
- Active Status: The Access Zone is enabled, ensuring that these configurations are applied when members attempt to gain entry.
Note: When using zonal configuration, birthday-based entry restrictions (stopping members at the gate based on their date of birth) cannot be configured within the system. This limitation should be considered when implementing access control policies.
Observation
Most of the time, member entries are determined by package rules. However, in many cases, the member’s package is not listed in the package-based rule, leading to denied access. It is advisable to verify whether the member’s package is allowed before attempting entry to avoid unnecessary rejections at the club.