Lock Assignments

Use the employees and locked fields on a shift to set an initial schedule or lock specific employee-shift pairings that the solver cannot change. These are parallel arrays: locked[i] controls whether employees[i] can be reassigned.

Use Cases

Warm start - Provide an initial solution for faster optimization
Fixed assignments - Lock confirmed shifts that cannot change
Partial planning - Keep some assignments fixed while optimizing others
Incremental scheduling - Add new shifts while preserving existing schedule

Warm Start

Provide an initial schedule without locking to help the solver find better solutions faster:

{
  "employees": [
    { "name": "Alice" },
    { "name": "Bob" },
    { "name": "Carol" }
  ],
  "shifts": [
    { "name": "shift-1", "from": "2024-01-01T08:00:00", "to": "2024-01-01T16:00:00", "min": 1, "max": 1, "employees": ["Alice"], "locked": [false] },
    { "name": "shift-2", "from": "2024-01-02T08:00:00", "to": "2024-01-02T16:00:00", "min": 1, "max": 1, "employees": ["Bob"], "locked": [false] }
  ]
}

With locked: [false], the solver uses these employees as a starting point but may reassign them if a better solution exists.

Locked Assignments

Lock assignments that must not change:

{
  "employees": [
    { "name": "Alice" },
    { "name": "Bob" },
    { "name": "Carol" }
  ],
  "shifts": [
    { "name": "shift-1", "from": "2024-01-01T08:00:00", "to": "2024-01-01T16:00:00", "min": 1, "max": 1, "employees": ["Alice"], "locked": [true] },
    { "name": "shift-2", "from": "2024-01-02T08:00:00", "to": "2024-01-02T16:00:00", "min": 1, "max": 1, "employees": ["Bob"], "locked": [true] },
    { "name": "shift-3", "from": "2024-01-03T08:00:00", "to": "2024-01-03T16:00:00", "min": 1, "max": 1 }
  ]
}

Locked assignments are treated as hard constraints. If they conflict with other hard constraints (e.g., skills, availability), the solution becomes infeasible.

Shift Properties

employees

array

Names of employees pre-assigned to this shift

locked

array

Parallel array to employees. locked[i] controls whether employees[i] can be reassigned by the solver

employees and locked are indexed positionally: the first entry in locked applies to the first entry in employees, and so on. Omit locked (or set an entry to false) to leave an employee assignable.

Mixed Locking

Combine locked and unlocked assignments for partial replanning:

{
  "shifts": [
    { "name": "shift-1", "employees": ["Alice"], "locked": [true] },
    { "name": "shift-2", "employees": ["Bob"], "locked": [false] },
    { "name": "shift-3", "employees": ["Carol"], "locked": [false] }
  ]
}

Alice stays on shift-1. Bob and Carol’s assignments serve as suggestions that the solver may improve.

Best Practices

When to use warm start

Large problems where finding any solution is slow
Incremental changes to existing schedules
Testing “what-if” scenarios from a known state

When to lock assignments

Employee has confirmed the shift
Contractual obligations require specific assignments
External constraints not modeled in the API

Avoid locking pitfalls

Don’t lock assignments that violate skills or availability
Leave flexibility for the solver to optimize
Use locked: false for preferences, locked: true only for requirements

Platform

VRP API

Fill API

Use Cases

Warm Start

Locked Assignments

Shift Properties

Mixed Locking

Best Practices

​Use Cases

​Warm Start

​Locked Assignments

​Shift Properties

​Mixed Locking

​Best Practices

Use Cases

Warm Start

Locked Assignments

Shift Properties

Mixed Locking

Best Practices