Skip to main content

Feasibility Check

As an additional service, the Automatic Rostering API provides a feasibility check as a pre-optimization step.

The feasibility check evaluates the validity of a payload, which ensures that the payload is correctly configured and that the optimization will run smoothly.

Getting started​

Check out the Quickstart section for how to connect with the API and become authenticated.

When you are ready to go, you can refer to the /feasibility endpoint to check the feasibility of a payload.

For more information on the endpoint, feel free to check out the API Reference. Most of it should look familiar, if you have already integrated the /jobs endpoint.

Feasibility Check Response​

The feasibility check provides results that can be categorized into two main types:

  • Infeasibilities: Issues that prevent the payload from being optimized.
  • Warnings: Issues that do not block optimization but might lead to suboptimal outcomes.

The response will include no more than 1000 infeasibilities or warnings per check. Please feel free to notify the team if your service requires more than 1000 infeasibilities or warnings to be returned.

A STATUS OF WARNING ...

Warnings in the feasibility check are used when certain configurations are used that may lead to suboptimal results.

One such example is the Employee-minutes-entire-roster-check, which will warn you if there is no combination of assigned shifts to a specific employee that will accumulate the required number of minutes for said employee.

So, it is not that the payload itself isn't able to be optimized, but the constraint itself means that there is no solution that satisfies the required employee minutes. This is returned as a warning, but your application may decide that this makes the payload infeasible, if you have a hard requirement on the number of minutes worked by each employee.

tip

If you receive a status of WARNING, you can still proceed with the optimization.

However, it is recommended to review the warnings and consider adjusting the payload to avoid potential issues.

A STATUS OF INFEASIBILITY ...

Infeasible payloads are not suggested to run through the optimization, as there is a contradiction in the payload that will make a solution impossible.

In general, what marks the difference between a warning and an infeasibility can be application specific. We therefore only specify infeasibilities for the most critical issues that will prevent the payload from being optimized.

We serve few infeasibility checks: One is the Cyclic-connected-shifts-Check, which will be returned if there is a cycle of shifts that are connected to each other, making an infinite loop of shifts that cannot be solved.

note

If you receive a status of INFEASIBILITY, but run the job through the optimization, it is undefined what the result will be.

Our feasibility checks may also fail during execution. This can happen if the check is too complex to be solved within the time limit, or (god forbid) an server-side error occurs during execution.

If a feasibility check fails, the reasoning can be found in the timeout or error fields of the response.:

  • Timeouts: List of specific feasibility checks that timed out (e.g., Cyclic-connected-shifts-Check)
  • Errors: List of specific feasibility checks for which another error occurred.

Response Properties​

The response from the feasibility check contains several properties that provide information about the check's results. Here are the descriptions of these properties:

  • Version: The version of the feasibility checker or solver. (Type: string)
  • Status: The list represents the overall status of the feasibility check. Each status is a string value. (Type: array of string items)
  • Warnings: Holds warning messages concerning potential non-critical issues. Each item in this array is an object structured as per the Warning definition. (Type: array)
  • Infeasibilities: Contains critical issues that render a given setup or scenario infeasible. Each item in this array is an object structured as per the Infeasibility definition. (Type: array)
  • Errors: Lists any errors that occurred during the feasibility analysis. Each error is a descriptive string. (Type: array of string items)
  • Infos: Holds additional information or messages from the feasibility check. (Type: array of string items)

See the API reference below for the response schema.

Feasibility Check response schema
version
required
string
status
required
Array of strings
required
Array of objects (warning)
required
Array of objects (infeasibility)
errors
Array of strings
timeouts
Array of strings
{
  • "version": "string",
  • "status": [
    ],
  • "warnings": [
    ],
  • "infeasibilities": [
    ],
  • "errors": [
    ],
  • "timeouts": [
    ]
}