Multiple Reasons for Unassigned Jobs

When a job can’t be assigned during route optimization, understanding why can help fixing the problem. Until now, our API returned only the single most likely reason. Sometimes that was misleading since it did not show the full picture.

Consider this scenario: You set up a sequence relation requiring job A to be delivered before job B. The optimization returns both jobs as unassigned with reason code 21: “could not be assigned due to relation constraint.” But removing the relation doesn’t help, the jobs still fail, now with code 2: “cannot be visited within time window.”

The relation wasn’t the root cause. It was the time windows. The relation just made the time window violation inevitable.

What’s New

The API now returns multiple reasons for each unassigned job, sorted by likelihood. This gives you the full context needed to diagnose and fix assignment failures.

Response Format

The details array in the response now includes a reasons field:

{
  "unassigned": {
    "services": ["job-1"],
    "details": [
      {
        "id": "job-1",
        "code": 21,
        "reason": "could not be assigned due to relation constraint",
        "reasons": [
          { "code": 21, "reason": "could not be assigned due to relation constraint" },
          { "code": 2, "reason": "cannot be visited within time window" }
        ]
      }
    ]
  }
}

The existing code and reason fields remain unchanged for backward compatibility (it still shows the most likely reason). The new reasons array provides up to 3 probable causes, ranked by how often each constraint blocked the job during optimization.

The feature is available now in the Route Optimization API. Check the API documentation for the full list of reason codes.

Happy Routing!