The core engine balances two conflicting goals: maximizing SLA adherence and honoring strict capacity thresholds. This page explains the sequential booking algorithm, showing how the engine transitions through standard availability, overbooking tiers, and out-of-SLA fallback settings.
Multi-Tiered Selection Logic
The system systematically sweeps available slot calendars down to a localized level. It operates sequentially according to the following strict order of operations:
Step 1: Ordinary Availability Evaluation (ORD)
The engine first looks for open slots that have a start date greater than or equal to the initial search date. This baseline search date is calculated using system parameters for the First Date, or derived from previous appointment dates for Further Date requests. The search window is restricted by the Service Expiration Date (SED).
To establish the reference limits, the Booking Service Level rules are fetched and cross-checked using a two-tiered fallback hierarchy:
-
Primary: Particular Work Order Type + Supply-related Township.
-
Secondary: General Work Order Type default rules (if no location-specific match exists).
[Service Expiration Calculation (SED)]
│
Is Request Date in the request in the past?
│
┌──────────────┴──────────────┐
▼ YES ▼ NO
Shift calculated expiration Shift calculated expiration
forward by service level days forward by service level days
starting from input date. starting from sysdate.
│
▼
[Compare with input 'serviceExpirationDate']
│
▼
System selects the LOWER of the two dates
as the definitive Call Reference SED[cite: 52].
Note: If the system-calculated date exceeds the input deadline, the engine logs an exception note ("Calculated Expiration Date greater than the specified date in the request") and locks the threshold directly to the input parameter.
For a slot to be successfully allocated under this tier, it must fulfill three conditions:
-
It must fall entirely within the timeframe set on the active planning grid.
-
The remaining ordinary capacity count must be strictly greater than zero (
> 0). -
It must be the earliest available time slot closest to the user's initial request.
Step 2: First-Level Extra Capacity Evaluation (OV1)
If no baseline ORD slots remain within the permitted window, the engine expands the search to use the OV1 parameters. It checks for system slots where the start date matches the configured Over1 Days Availability thresholds.
The slot must still be lower than the calculated service level deadline, fall within the planning grid timeframe, have an active OV1 remaining capacity greater than zero (> 0), and represent the earliest available option.
Step 3: Second-Level Extra Capacity Evaluation (OV2)
If overbooking capacity is completely depleted across the OV1 tier, the engine opens access to the OV2 capacity layer. The candidate slot must fall within the Over2 Days Availability start date rules, stay within the maximum planning timeframe, be beneath the valid SLA limit, and have a remaining OV2 capacity counter greater than zero (> 0).
Step 4: Final Exception Handling & Fallbacks
If all options across ORD, OV1, and OV2 are fully saturated up to the service expiration deadline, fallback logic is dictated by the "Booking possible over SLA" flag configured on the Work Order Type:
-
Flag = 0 (or Null): The system searches for an alternative slot within the existing SLA window by forcing allocation into the final available slot, even if this drives the ordinary availability counter negative.
-
Flag = 1: The engine will not force an appointment within the current SLA boundaries. Instead, it bypasses the SLA deadline and finds the first slot with available baseline capacity located later in the overall scheduling horizon.