Skip to content

Breaks and Private Appointments

A resource can be marked as unavailable for work for a period of time using private activities or breaks.

Private Appointment

A Private Appointment is a class of activity that defines a period of time in which a resource is unavailable for normal activities (for example, holiday, sickness, training, etc.). Private Appointments do not need an SLA, but need to be sent with a status committing the activity to a resource at a fixed date and time, and specifying its duration.

Breaks

Breaks will similarly define a period of unavailability for a resource, but do not need a fixed time at which they begin. There are two ways of defining breaks: explicit breaks (also referred to simply as breaks), and implicit breaks.

Explicit Breaks

Explicit breaks belong to their own class of activity, and are treated in the same way as activity calls, except that they do not typically have a location, but are assumed to take place at the location of the adjacent activity. Breaks have an SLA in the same way as normal calls, but should normally be given a higher base value than normal calls, to ensure that the breaks are scheduled into the route.

Breaks should be fixed to a particular resource, using the activity status, so that each resource has the correct number of breaks in each shift.

Implicit Breaks

Implicit breaks do not belong to any activity class, but rather are defined and treated as their own entity (see Shift_Break in the Scheduling Schema). This way, implicit breaks do not add extra activities into the Dynamic Scheduling Engine for scheduling. When the DSE makes changes to a plan, it does not consider making changes to the implicit breaks. Instead, the implicit breaks are deterministically placed into the plan, based on a set of rules. Implicit breaks do not have an SLA or base value, but will always be scheduled if it is possible to do so.

Note

Product Development strongly recommends the use of implicit breaks as they improve the performance of the system.

The rules that determine the placement of an implicit break into a route are as follows:

  1. The break must be scheduled if possible (i.e. unless it is impossible based on the input data, for example due to a private activity).
  2. The break must only be scheduled within the break window.

  3. The break will be scheduled as early as possible within the break window, according to the following:

    1. If the route is empty or all visits end before the break window it will be scheduled at the start of the window.
    2. If travel to a visit starts before the break window and the visit ends during the break window, then the break will be scheduled immediately after this visit.

    3. If a visit starts before the break window but ends after it:

      • If the activity is splittable, then the break will be scheduled after the min split time for the activity, provided this is within the window.
      • Otherwise the break will be scheduled at the start of the break window with the visit scheduled afterwards.

    4. If travel to a visit starts before the break window and the visit starts during the break window but ends after it:

      • If splitting travel around breaks is allowed, then the break will be scheduled immediately before the visit.
      • Otherwise if the activity is splittable, then the break will be scheduled after the min split time for the activity, provided this is within the window.
      • Otherwise the break will be scheduled at the start of the break window with the visit scheduled afterwards.

    5. If travel to a visit starts before the break window but ends after it:

      • If splitting travel around breaks is allowed, then the break will be scheduled as early as possible, splitting the travel.
      • Otherwise the break will be scheduled at the start of the break window with the visit scheduled afterwards.

    6. If travel to a visit starts after the start of the break window (e.g. because the visit has an availability restriction) then the break will be scheduled at the start of the break window, with the visit starting after the break. In this case the travel will potentially be scheduled before the break if splitting travel around breaks is allowed.

  4. If there is a fixed activity in the route (i.e. on site or fixed to resource and time) then the break will only be scheduled before the fixed activity if it can be done so validly. If not it will be scheduled after the fixed activity, provided that this is still in the break window and is valid. If no valid time can be found, then the break will not be scheduled. In this case the route will be treated as valid unless the break could have been validly scheduled but a non-fixed activity prevented this from happening.

  5. If there is a travelling activity overlapping the break window then the usual rules will apply, except that if splitting travel around breaks is not allowed, and the visit ends after the break window, then the break will not be scheduled.

For a parallel resource (see Scheduling Concepts - Resource Capacity Management for more details) implicit breaks are scheduled differently. Travel need not be considered since travel is not supported for parallel resources.

Implicit breaks are scheduled to parallel resources as follows:

  1. If the route is empty or all visits end before the break window it will be scheduled at the start of the window.
  2. If there are any times in the break window where all activities end, the break will be scheduled at the latest of these times.
  3. If there are no times in the break window without any activities scheduled, any positions in the window where splits could occur will be calculated (a split can only occur where all activities to be split are past their minimum split). The earliest of these positions with the fewest number of splits will be chosen for the implicit break, with priority given to choosing the fewest number of splits.
  4. If there are no suitable times within the break window to split the activities, the break will be placed at the start of its break window with the activities within the window then being scheduled after the break.
  5. If there is a fixed activity in the route (i.e. on site or fixed to resource and time) then the break will only be scheduled before the fixed activity if it can be done so validly. If not it will be scheduled after the fixed activity, provided that this is still in the break window and is valid. If no valid time can be found, then the break will not be scheduled. In this case the route is treated as valid unless the break could have been validly scheduled but a non-fixed activity prevented this from happening.