Skip to main content

Integrating with the Feasibility Check

Responses from the feasibility check are based on a unified interface of properties that are common to various types of infeasibilities.

This approach involves grouping all properties that might indicate a warning or flaw in the schedule under a single "Violation" object in the response.

For all of the feasibility checks, we will specify in the documentation which values are used.

The current exhaustive list of all properties available is listed below.

PropertyTypeDescription
DayintegerRepresents a specific day in the roster, when scheduling with a recurring schedule type. (If scheduling 30 days, this value ranges from 0 → 29)
DatedateDenotes a specific date in the roster, when scheduling with the calendar schedule type.
DemandSegmentobjectContains the StartTime, EndTime, and MinDemand for a demand segment. This specifies a specific demand segment in the roster, usually a reference to uncovered demand.
ShiftstringRepresents a shift with specific properties such as Name, WeekendNumber, RequiredEmployees, EmployeeNumber, RequiredMinutes, AchievableMinutes, StartTime, EndTime, MnAssignment, TaskId, WorkType, NumberOfEmployees, MissingMinutes, TotalMinutes. Each of these properties provides further specifics about the violation.
WeekendNumberintegerRepresents the weekend number in Demand-weekend-covered-by-employees-check - it is very specific to this check, and may be refactored in the near-future.
RequiredEmployeesintegerRepresents the number of employees - often for what is required to cover a demand segment.
EmployeeNumberstringRefers to specific employees.
RequiredMinutesintegerRepresents the number of minutes required in the violation.
AchievableMinutesintegerRepresents the number of minutes that are reachable in the violation.
StartTimestringRepresents the start time of the violation.
EndTimestringRepresents the end time of the violation.
AssignmentstringRefers to a specific assignment
WorkTypestringRefers to the type of work.
NumberOfEmployeesintegerRepresents the number of employees in the violation.
MissingMinutesintegerRepresents the number of minutes missing in the violation.
TotalMinutesintegerRepresents the total number of minutes in the violation.
MissingEmployeesDueToWeekendDistributionintegerRepresents the number of missing employees due to weekend distribution. (subject to be changed soon, and replaced with missingEmployees)
Perhaps more to come as we expand the checks...

This structure allows for the addition of new checks in the future without altering the response format. Thus, integrators can easily adapt to changes. Descriptions for each check are provided to aid in understanding new checks without the need for immediate integration.

This ensures backward compatibility without requiring changes to the integrator's code or versioning.

This is also why we add a description to all of our checks, which, in the case you haven't gotten around to translating yet (if the check is new), can be used to understand the issue. This way, you don't necessairly have to discard new checks that you haven't integrated yet - you can just receive them as all the properties are known to you.

This allows the service to be backwards compatible without any changes to the integrator's code, and without versioning.

In the future, there will be changes to the violation objects, and you, as a integrator, will have to expand the fields of your parsing, however, this will be communicated in due time.

Breakdown Warning & Infeasibility​

Warnings and infeasibilities share the same structure but differ in their type.

It's recommended to review the feasibility checks to identify any that are considered infeasibilities, such as the Cyclic-connected-shifts-Check, which prevents the solver from scheduling a shift.

Properties​

  • Title (type: string): The name or identifier for the specific warning or infeasibility, for example Demand-weekend-covered-by-employees-check.
  • Category (type: string): Warning or Infeasibility
  • Description (type: string): A detailed description about the check.
  • Violations (type: array): An array of Violation objects detailing specific instances of the issue (shown above).

Which type of checks are warnings, and which are infeasibilities, are defined in the title of the response schema as enums.

Infeasibility Response Schema
title
required
string
Enum: "Cyclic-connected-shifts-Check" "Prioritization-hard-constraint-locked-shift-check"
category
required
string

This category is always set to INFEASIBILITY

description
required
string
required
Array of objects (violation)
{
  • "title": "Cyclic-connected-shifts-Check",
  • "category": "string",
  • "description": "string",
  • "violations": [
    ]
}
Warning response schema
title
required
string
Enum: "Employee-availability-check" "Demand-weekend-covered-by-employees-check" "Employee-minutes-weekly-check" "Employee-minutes-entire-roster-check" "Demand-covered-by-shift-templates-check" "Shift-is-covered-by-demand-check" "Employee-assigned-to-shift-covers-demand-check" "Shift-Templates-are-demand-relevant-check" "Shift-utilization-minimum-occurrence-check" "Locked-shift-task-requirements-check"
category
required
string

This category is always set to WARNING

description
required
string
required
Array of objects (violation)
{
  • "title": "Employee-availability-check",
  • "category": "string",
  • "description": "string",
  • "violations": [
    ]
}

Sample Response Explanation​

Now you should be ready to start diving into the feasibility check examples. All of our checks are documented and contain a sample payload/response. Enjoy the journey!