Documentation

Learn how to use HeadOps

From initial workspace setup to advanced scheduling engine configuration — everything you need to transform your production planning workflow.

When you first sign in to HeadOps with your Google account, a Workspace is automatically provisioned for you. A workspace is your company's secure data boundary — all projects, teams, stage types, and holiday calendars are scoped to it.

Inviting Team Members

Navigate to Settings → Workspace to manage your team. Invite colleagues by entering their email address and selecting a role:

Admin — Full access including workspace settings, member management, and danger zone operations.
Editor — Can create and modify projects, components, stages, and allocations.
Viewer — Read-only access to the timeline and team views.

Security: HeadOps enforces Row Level Security (RLS) at the database layer. Users can only see and modify data within their own workspace, even at the API level.

HeadOps organizes your production data in a strict four-level hierarchy.

Workspace (your company boundary)
└── Project (order number, client, delivery date)
└── Component (physical part: "353 - STC D")
└── Stage (manufacturing step: "Pre-weld", "Paint")
└── Allocation (team + start/end dates)

Projects

A Project represents a single client order or conveyor installation. Each project has an order number, a client name, and an official end date that serves as the deadline.

Components

A Component is a physical piece within a project. Components appear as individual rows on the planning timeline.

Stages

A Stage is a manufacturing step required for a component — such as "Pre-weld", "Electrical Install", or "Testing". Each stage has a defined duration in working days.

Allocations

An Allocation is the scheduled assignment of a team to complete a stage. Allocations appear as colored blocks on the Gantt canvas, and can be dragged to trigger automatic rescheduling.

Defining Stage Types

In Settings → Stage Types, define the types of manufacturing stages your factory uses. Each stage type has a name, a default duration (in working days), and a color that will appear on the timeline.

Linking Teams to Stage Types

Teams can be associated with one or more stage types, defining which kinds of work they are capable of performing. This many-to-many relationship powers the Auto-Allocation Wizard.

Example: If your "Welding Alpha" team is linked to both "Pre-weld" and "Weld" stage types, the Auto-Allocation Wizard will consider them for either type of stage.

Working Week Configuration

By default, all teams operate on a standard Monday-to-Friday (5-day) working week. However, individual stages can be set to a 6-day mode (Monday-to-Saturday).

Public Holidays

Navigate to Settings → Public Holidays to manage your workspace's holiday calendar. When a stage has "observe holidays" enabled (the default), the scheduling engine will skip holiday dates when calculating end dates.

Navigating the Canvas

The planning timeline is a full-featured Gantt canvas. The left side displays a two-column hierarchy of project order numbers and component names. The right side is the scrollable timeline with day columns, weekend shading, holiday markers, and a blue "today" indicator.

Adding Projects and Components

Click the "+ New Project" button in the top-left corner of the canvas to create a new project. Within a project row, click the "+" button to add components.

Scheduling Stages

Backlog stages appear in the component's expanded panel. Drag a backlog stage onto the timeline to create an allocation.

Rescheduling

Drag any existing allocation block to a new date. HeadOps will automatically compute the cascade effect using the EDF rescheduling engine. If the move would cause new deadline violations, you'll see a warning modal.

Under the Hood

How the Scheduling Algorithms Work

You don't need to be a software engineer to understand how HeadOps thinks. Below is a plain-English explanation of every algorithm that powers the scheduling engine.

HeadOps solves this with a day-by-day counter. Starting from a given date, it walks forward through the calendar, one day at a time, and only counts the days that qualify as "working days." It skips:

Weekends — Saturdays and Sundays in 5-day mode, or just Sundays in 6-day mode.
Public holidays — any date you've added to your workspace's holiday calendar.

Why this matters: If you add a national holiday to your calendar, every stage that spans across that date automatically extends by one calendar day — without you having to touch a single block.

Imagine you have three stages lined up back-to-back: Pre-weld → Weld → Paint. If you push Pre-weld forward by 3 days, you'd expect Weld and Paint to shift forward by 3 days too. That's exactly what HeadOps does — but smarter.

How It Works

When you drag an allocation block to a new date, HeadOps measures the working-day gap between the moved stage and every later stage in the same project. It doesn't count raw calendar days — it counts the actual working days between them.

Duration changes too: This same algorithm also kicks in when you change the duration of a stage. If Pre-weld grows from 3 days to 5 days, all downstream stages will automatically shift forward to preserve their original spacing.

This is the "big brain" of HeadOps. When you move a component, the engine doesn't just cascade stages within that project — it checks whether your move has accidentally double-booked a team, and if so, it intelligently reshuffles the affected work across your entire factory.

Phase 1: Lock Your Move

The engine starts by honoring your decision. It schedules all stages of the component you moved, starting from the new date you chose, and marks those teams as "busy".

Phase 2: Find the Affected Work

Next, the engine scans every other component in the system and asks: "Does any of this component's stages use the same team, on overlapping dates?" Only components that answer "yes" are flagged for rescheduling.

Phase 3: Sort by Urgency (Earliest Deadline First)

The flagged components are now arranged in a priority line. The component with the closest delivery deadline goes first.

Why deadlines first? This is a well-known strategy in scheduling theory called "Earliest Deadline First" (EDF). The intuition is simple: the work that has to be done soonest should get first pick of the available team slots.

Phase 4: Fill the Gaps

Now, for each component in the priority queue, the engine schedules its stages one by one. For each stage, it asks: "When is the assigned team next available?" It uses an efficient jump-ahead technique — instead of checking every single day, it skips over entire blocks of busy time.

Phase 5: Check For Deadline Violations

Finally, the engine checks every component's last stage to see if it finishes after the delivery deadline. If so, it calculates exactly how many days overdue the project will be.

When you add a new component with multiple stages, you face a combinatorial puzzle: each stage can potentially be assigned to several different teams. The wizard tries them all.

Step 1: Find Eligible Teams

For each stage, HeadOps looks at the stage type and finds all teams that are linked to that type.

Step 2: Generate All Combinations

The engine creates every possible combination of team-to-stage assignments. A built-in safety guard caps this at 100,000 combinations to keep things fast.

Step 3: Simulate Each Schedule

For every combination, the engine simulates the schedule as if you had manually placed each stage. It checks each team's existing calendar, finds the earliest available slot that doesn't conflict.

Step 4: Pick the Winner

The combination that produces the earliest overall finish date wins.

Real-world example: A component has 4 stages (Pre-weld, Weld, Electrical, Testing) with 3 eligible teams each. The wizard evaluates all 81 combinations in under 50 milliseconds.

A "conflict" in HeadOps means a single team has been assigned to two different stages whose date ranges overlap.

How Detection Works

The engine groups all allocations by team. For each team, it sorts its assignments by start date and then scans through the list looking for overlaps. When an overlap is found, both allocation blocks are flagged as "conflicted" with a red overlay on the canvas.

Resolving Conflicts

You have two options. You can manually drag one of the conflicting blocks to a new date — which triggers the cascade and dynamic rescheduling algorithms described above. Or you can click "Reschedule All", which triggers a global reschedule that rebuilds the entire factory schedule from scratch.