Docs
  • Solver
  • Models
    • Field Service Routing
    • Employee Shift Scheduling
    • Pick-up and Delivery Routing
    • Task Scheduling
  • Platform
Try models
  • Task Scheduling
  • Real-time planning

Task Scheduling

    • Introduction
    • Getting started: Hello world
    • User guide
      • Terminology
      • Scheduling API concepts
      • Integration
      • Constraints
      • Using the API
        • Using the OpenAPI spec
        • API tooling
      • Demo datasets
      • Input datasets
        • Model configuration
        • Model input
      • Output datasets
        • Metadata
        • Model output
        • Input metrics
        • Key performance indicators (KPIs)
      • Job types and machine types
      • Resource-specific durations
      • Freeze jobs until
      • Metrics and optimization goals
      • Score analysis
      • Validation
    • Machine and employee resource constraints
      • Machine unavailability
      • Resource transitions
      • Employee resources
    • Job service constraints
      • Time windows
      • Time management
      • Job dependencies
      • Priority jobs
      • Tags and specific resources
    • Real-time planning
    • Changelog
    • Upgrading to the latest versions
    • Feature requests

Real-time planning

Every schedule is subject to change. New jobs may be added, existing jobs may be cancelled, or a production machine may become unavailable.

To reflect the changes in the schedule, or to improve the schedule further, you can re-plan the jobs, with keeping the existing assignments from the previous plan as a part of the input.

{
  "machines": [
    {
      "id": "machine A",
      "start": "2027-02-01T00:00:00+00:00",
      "jobs": [
        "job 1",
        "job 2"
      ]
    }
  ]
}

However, including the assignments does not guarantee the jobs will be assigned to the same machine as before.

For example, if a job is already in progress on a machine, it should not move to a different machine as a side effect of re-planning.

To make sure the assignment is always kept, you can pin the job to the machine.

{
 "machines": [
    {
      "id": "machine A",
      "start": "2027-02-01T00:00:00+00:00",
      "jobs": [
        "job 1",
        "job 2"
      ]
    }
  ],
  "jobs": [
    {
      "id": "job 1",
      "duration": "P5D",
      "pinned": true
    },
    {
      "id": "job 2",
      "duration": "P10D"
    }
  ]
}

In this example, job 1 is pinned to machine A, while job 2 is not. Job 2 may be assigned to a different machine during re-planning.

Pinning also guarantees that the start and end of the job processing does not change after re-planning. For that reason, you can pin a job only together with every preceding job on the machine.

There is no need to bring completed jobs into the re-planning input unless that have impact on the future jobs.
  • © 2026 Timefold BV
  • Timefold.ai
  • Documentation
  • Changelog
  • Send feedback
  • Privacy
  • Legal
    • Light mode
    • Dark mode
    • System default