Auto-scheduling
Auto-scheduling keeps your Gantt honest. When you move or resize a task that has successors, Foundation pushes those successors forward so dependency constraints still hold. The goal is simple: you should never have to manually walk a chain of linked issues to keep the schedule in sync.
Auto-scheduling runs automatically whenever dates change. You don’t turn it on — it’s always watching.
What triggers a cascade
Section titled “What triggers a cascade”Foundation’s schedule engine runs on every path that changes dates:
- Gantt bar drag or resize — moving or resizing a predecessor.
- Grid date edits — editing Start Date or Due Date cells.
- Dependency changes — creating, deleting, or editing a dependency’s type or lag.
- Sync Agent runs and imports — bulk date changes from server-side operations.
- Rovo and automation mutations — anything touching dates through the API.
- Lens load — on open, Foundation reconciles any violations it detects.
Any of these can start a cascade if a linked successor would be left behind.
How the cascade behaves
Section titled “How the cascade behaves”- Forward-only. Foundation pushes successors later to satisfy constraints. It does not pull successors earlier automatically — if you want to pull work in, edit the successor directly.
- Working days. Lag and lead time are measured in working days. Weekends are skipped.
- Ghost preview. During a bar drag, translucent ghost bars show where successors would land. Commit the drag to apply the change; release without dropping to cancel.
- Toast + undo. When a cascade completes, a toast summarizes the change (“3 successors moved”). You have 60 seconds to undo.
- Schedule Log. Every cascade is recorded in the Schedule Log tab in the Inspector. Each entry lists the source issue, affected successors, and old vs new dates. You can copy the log as Markdown for audit.
Manual and locked scheduling
Section titled “Manual and locked scheduling”Two escape hatches exist when you need the schedule to stay put:
- Manual — pin a task’s dates and they won’t move, even if a predecessor shifts.
- Locked — explicitly prevent the schedule engine from touching the task.
Set these on an issue when its dates are externally committed (a customer-promised date, a regulatory deadline) and should not cascade.
What happens on conflicts
Section titled “What happens on conflicts”If cascading would produce an inconsistent schedule — say, a rule that can’t be satisfied — Foundation flags the conflict on the bar. You can:
- Auto-schedule to clear the conflict and let the engine choose new dates.
- Respect link to keep the constraint and adjust the dependent task’s Start Date to match.
Rate-limit errors or permission errors mid-cascade surface in the toast and in the Schedule Log, so you always know when a cascade was partial.
Loop prevention
Section titled “Loop prevention”Foundation has hard stops against runaway cascades. If reconciliation starts oscillating on the same issues pass after pass, it halts automatically and warns: “Auto-schedule halted — Scheduling is oscillating on N issues. Check dependency constraints for conflicting rules.” That’s your cue that two rules are fighting — usually impossible lag values or an overconstrained cycle fragment.
- Add dependencies before moving dates. Auto-scheduling only helps if the graph knows about the relationship.
- Keep cascades scoped. Foundation caps a single cascade at a reasonable number of issues. Very large moves may need more than one pass.
- Watch the Schedule Log after a big change. It’s the fastest way to see what shifted.