OptaPlanner and its commercial forks for workforce scheduling

Constraint solvers built on OptaPlanner’s lineage get compared as if the choice were purely a feature question. It rarely is. A handful of commercially supported forks now descend directly from OptaPlanner, built in part by people who worked on the original. For a team scheduling a field workforce, the useful comparison is not feature-by-feature. It is about what you are buying and what you still have to build yourself.

What is the same

The mental model. Planning entities, planning variables, hard and soft constraints, a score. A team that understands OptaPlanner’s constraint streams understands a commercial fork’s just as well. Constraint models port with effort, not with a rewrite.

The solving approach. Construction heuristics followed by local search, the same family of metaheuristics, the same tuning levers. Solve quality on a well-modelled problem is not usually where these options diverge.

What differs

Maintenance and support model. The substantive difference. A maintained commercial product with people to call is a different proposition from an open-source line whose maintainers have moved on to other projects. For a workforce scheduler that dispatches real crews to real sites, that is usually the whole argument.

Deployment shape. Some commercially supported forks offer a managed API alongside the embeddable library. If you would rather call a service than own solver infrastructure, that option increasingly exists. Whether it suits you depends on data residency and how tightly the solve is coupled to your transaction path.

Domain models. Some options ship pre-built models for common shapes, including field service routing and employee shift rostering. If your problem is close to a standard shape, you start further along. If it is genuinely unusual, you are modelling from primitives either way.

What the comparison misses

None of these engines know anything about your workforce. All of them take a description of jobs, people, skills and availability, and return an assignment. Where scheduling projects fail is almost never in that step. It is that the description handed over was wrong: certifications not recorded against people with expiry dates, no absence calendar so someone on leave was schedulable, no planned start on the work order so the result had nowhere to land, and a subcontractor pool that is not in the system at all because they were never issued seats.

A better engine solving a fictional model produces a schedule that gets overridden on Tuesday, exactly as the previous one did. If your planner rebuilds a large share of the week by hand, the engine choice is not your first problem.

How to sequence it

Audit the inputs before choosing an engine. Can you answer, from the system rather than from a person: who is certified for this task and was their certification valid on the date they did it; who is available next Thursday; is the part reserved against this job; when do we intend to do this, as distinct from when it is due. If several of those answers live in a spreadsheet or a person’s head, fix that first. It is unglamorous and it is what makes the solver’s output survive contact with the week.

Then choose the engine on maintenance posture and fit, not on benchmark solve times. For most teams that means picking a properly supported option, because supported beats unsupported for anything dispatching real crews, and the migration path away from an unmaintained OptaPlanner line is usually the shortest one available.

Facterra sits on the records side of this line. We hold the asset, work-order, competency and availability data, assemble it into constraints, and call OptaPlanner. We do not build optimisation and will not; that layer belongs to the people who do nothing else. If you are weighing an engine decision and suspect the real gap is upstream in your records, that is the conversation we are useful in.