# Zonal Access Control Logic and Execution Order

HTML version: [Zonal Access Control Logic and Execution Order](https://support.gladstonesoftware.cloud/kb/zonal-access-control-logic-and-execution-order)

## Problem
You need to understand how conditions are evaluated in a zonal access control configuration, including the execution order, how "OR" logic works and how failed checks affect what is checked next, so that access is granted or denied correctly.

## Resolution

1. **Understand the condition evaluation order**
   - Conditions are checked one by one, from top to bottom, in the order set by the system administrator.
   - The order can also depend on when the conditions (rules) were created.
   - A typical initial sequence is:
     1. **Entry Point Check:** verifies that the member is trying to access a valid zone.
     2. **Alert Priority Check:** checks for active alerts that could block access.
     3. **Status Check:** confirms that the member's status allows access (for example, active and not suspended).
     4. **Site Check:** confirms that the member is linked to the correct site.

2. **Understand how failed conditions are handled (OR logic)**
   - If a condition fails, the system moves on to the next set of conditions in the same "OR" block, again from top to bottom.
   - This allows alternative ways for access to be granted if an earlier check fails.

3. **Follow an example: high-priority alert**
   - The system checks the Entry Point. If it is valid, it checks Alert Priority.
   - If a high-priority alert makes that check fail, the system moves to the next condition in the OR block, such as the member's Package.
   - If the member has the correct package, the remaining conditions (for example Status and Site) are checked. If the package is not valid, access is blocked.

4. **Remember that previous conditions are not rechecked**
   - Once evaluation moves to a new block because a condition failed, earlier conditions are not revisited unless a new, separate logic block is added.
   - If all checks in the current block fail, access is denied.

5. **Add further condition blocks (if applicable)**
   - Add conditions to control access more tightly. Each new block follows the same top-to-bottom order.
   - Example block: Package Check > Entry Point Check > High Priority Alert Check > Package OK Status Check.

6. **Decide the order as the administrator**
   - The system administrator configures which conditions are used and in what order, based on your organisation's priorities and access policies.

7. **Deactivate old rules rather than deleting them**
   - When you create new rules, **deactivate** the old ones instead of deleting them.
   - Deleting a rule does not remove it from the front desk system, so an old rule may still allow access even when the newer rules fail.

8. **Check the access zone settings**
   - The Club Centric zonal set-up uses these values:
     - **Grace Period**: how long a member can re-enter the zone without a new entry. Set to 0 minutes, so every entry is logged.
     - **Passback Period**: how long after the grace period re-entry is blocked. Set to 1 minute.
     - **Monitoring Mode**: set to **Semi Monitored**, so staff make manual checks only if issues or alerts arise.
     - **Active Status**: make sure the access zone is enabled, or its configuration does not apply.

## Notes

- The order of conditions affects both security and convenience; customise it to enforce your access rules accurately.
- Access is most often denied because the member's package is not included in the package-based rule. Check that the member's package is permitted before they try to enter, to avoid unnecessary rejections.
- Entry restrictions based on date of birth (for example, birthdays) cannot be set up in zonal configuration.
- The same zonal logic applies in the Club Centric system.
- Related: [Configuring Access Control Entry Point Profiles in the GMC](../gladstone360/access-control-entry-points-and-entry-point-profiles.md).
