Understand Direct Future Scheduling

This page describes the functional logic, background mechanics, engine optimization rules and testing parameters of Direct Future Scheduling: automated, low-latency injection of targeted future Work Orders into the live schedule, alongside the platform's broader capacity and routing evaluation.

Activity identification and filtering

To determine which Work Orders qualify for Direct Future Scheduling, the system uses a rules engine modeled on standard WO Filters. Configuration is found under Scheduling Optimization > Configuration and is restricted to users with edit permission.

When a new Work Order is created:

1. The system first checks whether it qualifies for Emergency Response. If it does, Direct Future Scheduling evaluation stops here.

2. If it does not qualify, the Work Order is evaluated against the active Direct Future Scheduling rules, in their configured sorting order.

3. As soon as a rule matches, evaluation stops immediately, and the Work Order is staged in the support table together with the ID of the matching rule.

Note: evaluation always stops at the first matching rule — later rules are never evaluated for that Work Order.

Task triggering and processing

Direct Future Scheduling processing can start in two ways:

Calendar-based background queue. A periodic background task checks, for each Model/Operation Center combination, whether a valid calendar window is currently open (based on the day of the week, the target processing interval and the configured frequency) and whether enough time has elapsed since the last run. When both conditions are met, a new processing record is created. A dedicated runner then picks up pending records from the staging table — a staged Work Order is eligible only if it is still in a schedulable state and has not exceeded the maximum number of execution attempts set in the company properties.

Manual and interactive triggers. A dispatcher can manually select an optimization model and run it against the staged Work Orders on demand. The system natively guards against overlapping executions, so a manual run and a scheduled background run can never process the same scope at the same time.

Managed entities

Direct Future Scheduling evaluates three kinds of entities, balancing real-time operational constraints against the business parameters configured for the model.

Activities

• Real schedule activities: activities already committed to a technician's live timeline are treated as locked to that resource. The engine can shift them horizontally — changing their start/end time within the shift — but cannot unassign them or move them to a different technician.

• Explicitly selected and filter-extracted activities: new or backlogged Work Orders enter the optimization scope either through manual dispatcher selection, or automatically, by matching an active Direct Future Scheduling rule and its filter.

• Multi-day tasks: long tasks spanning several days are supported natively. For already assigned activities, the first day's slice is sent with the constraint lastOfDay, the last day's slice with firstOfDay; any days in between are sent as standard pre-assigned activities with lunchWorking=true.

• Customer appointments: a scheduled appointment locks its timeline slot. To protect it and be aligned with Gisware logic, the calculated end of the appointment window is automatically extended by the exact duration, in minutes, of the planned task.

• Bundles and multi-operation sequences: for a bundle or a multi-task Work Order managed by order, the engine processes only the first operation, with its duration set to the sum of all the embedded operations' durations.

Resources and teams

• Technicians and crews: the engine handles individual technicians, Fixed Teams, and Crew Shells.

• On-duty standby availability: a shift can be Normal (ordinary work, shown in green on the Daily Plan), On Duty (standby coverage, shown in light blue), or On Duty Only. The engine reads these as system-generated skills — O for ordinary, R and R2 for the two standby modes — so that a Work Order configured for a given state is only ever scheduled to a technician in that same state, per the active Simulation Rule.

• Calendar adjustments and unavailabilities: time off, partial-day permits or last-minute unavailabilities change a resource's availability in real time. Depending on where they fall, the system either truncates the start/end of the shift, or — for a mid-shift gap — inserts a dummy activity (type AS, at the resource's own coordinates) that blocks real work from being scheduled in that window.

• Mixed teams: resources belonging to a mixed team are sent to the engine as individual single-member teams. Each team's pre-assigned activity is cloned per member; the clones are then linked with timeConstraint elements using type="start-start", requiredAssignment="true-true", offsetMin="0m", offsetMax="0m" — forcing every clone to be scheduled at exactly the same time.

Rules and functional boundaries

• Day occupancy rules: a technician's available hours are modeled as a finite stock in a virtual warehouse, with a percentage- or minute-based cap per task group. Once a technician's capacity for a group is used up, no further activity of that type can be added to their timeline. This capacity check is currently applied to new tasks and to activities already assigned to the resource.

• Scheduling areas: during optimization, the system assigns the Scheduling Area as a skill both to the technician/team (per configuration) and to the activity (per its location), and requires an exact match between the two — a hard constraint that keeps activities inside their authorized zone.

• Resource preferences: a Mandatory Technician binds the activity directly to that team's skill; a Preferred Technician generates a temporary duplicate of the activity linked via exclusionGroup, favoring that resource without blocking assignment elsewhere; an Excluded Technician gets a negative constraint that prevents assignment.

• No-scheduling slot rules: a candidate activity's <days> element starts as a full day, then the blocked interval is subtracted according to its range type — Start extends the preceding slot by the activity's duration (an activity may not begin inside the window, but may already be running when it starts); Execute removes the window entirely, so only slots fully outside it are sent to Gisware.

• Travel exclusions: when a resource is flagged "No transfer at start/end of day," the standard home-location start/end coordinates are dropped from the route; the engine calculates travel to/from the first and last job independently, via standalone search-path calls. Other options are managed using the same logic.

• Permits: a blocking permit's validity is checked when the Gisware request is built. A Work Order with no valid permit for the whole execution horizon is dropped entirely from the request. Where the permit's validity only partially overlaps the horizon, the activity's <days> slots are restricted to the authorized days only.

• Multi-stage dependencies: a multi-stage constraint between already-assigned operations and eventually a new one to be assigned is treated as a hard constraint. It is mapped into the request's timeConstraints section, and the new operation is scheduled respecting the configured time relationships.

Optimization core engine logic

The model computes optimal drop-in assignments directly on the real timeline, under two governing constraints:

• Never-remove lock: an activity already assigned on the Daily Plan must stay with that same resource. The engine may shift it horizontally within the day, but it can never be unassigned or handed to a different technician.

• All-or-nothing exclusion: the engine does not use pre-fixed sequencing. If it impossible to keep an existing activity on its technician, that resource is excluded from the run entirely (an All-or-Nothing check), rather than partially rearranged.

Search horizon: the horizon is the interval between the earliest possible start date and the earlier of the strict deadline or the model's configured maximum optimization horizon.

• Model delta controls: a model can shift the start date by a configurable number of days (+/-), scoped by Work Order type or Operation type. The end date is calculated as the earliest of: the cardinal end date, the Max Scheduling Horizon configured on the model, and the Max Scheduling Horizon company parameter

• Sub-period execution: the resulting horizon can be split into shorter sub-periods, per the model's configured duration; the engine then submits one sequential request per sub-period instead of a single request for the whole horizon.