Major Milestones
A Major Milestone is a special type of task that represents a significant checkpoint or phase gate in a project. Rather than being a piece of work to perform, a milestone is a goal to reach — a target window by which a certain phase of the project should be complete.
Major Milestones are first-class objects in Compass: they appear in the task dashboard, have their own progress tracking, and can have many tasks contributing to their completion. Their dates define a planning window that groups and contains the work underneath them.
What makes a milestone different from a regular task
A regular task is something you do. A milestone is something you reach.
| Regular task | Major Milestone | |
|---|---|---|
| Represents | Work to be performed | A project checkpoint or phase gate |
| Dates | Start date and due date | Start date and due date — defines a planning window |
| Progress | Set manually (percent complete) or by completing the task | Automatically calculated from related tasks |
| Related tasks | — | Can have many tasks that feed into it |
| Assignee | Yes | Yes, when no related tasks are linked (see below) |
| Blocks project | Optionally (Will Delay Project Completion) | Optionally |
| Used as date reference | — | Yes — tasks can be timed "relative to this milestone" |
| Gantt chart | Always a bar | Bar when the milestone spans a date range; diamond when it's a single date |
Creating a Major Milestone
To create a Major Milestone, create a Task Catalog Item and enable the Major Milestone toggle in the Task Rules and Logic section.
A milestone catalog item has all the same settings as a regular task item — title, timing (relative dates), duration, assignment, approval, etc. — with one additional concept: Related Tasks.
When tasks are generated for a project, the milestone appears in the task list as a special item. Its progress percentage is automatically calculated from its related tasks.
Milestone dates: start date, due date, and duration
Milestones support full date management, just like regular tasks. A milestone can have a start date, a due date, and a duration. Together, these define the time window during which the milestone's work should happen.
Two ways to define milestone dates
Manual dates — set the start date and due date directly. This is the simplest approach: you pick the dates and Compass uses them as-is.
Relative dates with duration — set the due date relative to a project date (or another milestone's due date), specify a lead time, and define a duration. Compass calculates the due date from the reference, then auto-calculates the start date:
Start Date = Due Date − Duration
When the reference date changes (and "Adjust dates if reference changes" is enabled), both dates update automatically.
Example — relative dates:
Project Primary Completion Date: June 1
Lead Time: 30 days
Duration: 20 days
Due Date = June 1 − 30 days = May 2
Start Date = May 2 − 20 days = April 12
→ Milestone runs from April 12 to May 2
Both approaches are fully available for milestones. Both dates are optional — a milestone can have only a due date, only a start date, or no dates at all.
What happens when you switch between modes
If a milestone is set up with relative dates and you manually edit the due date or start date, the milestone switches to manual mode — the "Due Date Relative To" setting is cleared, and both dates become directly editable. This prevents the system from overwriting your manual change on the next recalculation.
Editing the duration while in relative mode keeps relative mode active — the system recalculates the start date based on the new duration.
How milestones appear on the Gantt chart
How a milestone renders on the Gantt chart depends on its resolved dates:
| Date state | Gantt rendering |
|---|---|
| Start date + due date (different dates) | Bar/span — visually distinct from regular task bars |
| Start date = due date | Diamond — a single point in time |
| Due date only (no start date) | Diamond |
| Duration = 0 (in relative mode) | Diamond — start equals due after calculation |
| No dates set | Not shown on Gantt |
Milestone bars are visually distinguishable from regular task bars (different color or styling) so you can tell at a glance which items are milestones.
Related Tasks
Any Task Catalog Item can be linked to a Major Milestone via its Related Milestone setting. When the task is generated on a project, it becomes a "related task" of that milestone.
The milestone's progress is:
Milestone Progress = (Completed Related Tasks / Total Related Tasks) × 100%
Example: The "Guest Rooms Ready" milestone has 80 related tasks (room inspections, FF&E installation items, housekeeping setup tasks, etc.). When 40 are completed, the milestone shows 50% progress. When all 80 are done, the milestone shows 100% — and can be marked complete.
This gives stakeholders a clear, real-time view of where a major phase stands, without having to manually track dozens of individual tasks.
Milestones as planning windows — date containment
When a milestone has start and due dates defined, those dates represent the intended target window for the work grouped under it. Related tasks should fall within that window, but Compass does not force them to — it informs you and lets you decide.
This is a deliberate design choice: milestones often represent a managerial target that may be intentionally tighter or looser than the actual task spread. Compass warns you about mismatches instead of silently preventing them.
How containment works
When you make a change that causes a related task's dates to fall outside its milestone's date range, Compass shows a confirmation dialog explaining the conflict and offering options:
When you change a milestone's dates and related tasks are now outside the new range:
- Adjust milestone dates to fit — expand the milestone to the smallest range that contains all related tasks
- Keep new dates anyway — save your change as-is (out-of-range tasks will be flagged)
- Cancel — discard the change
When you create or edit a related task with dates outside the milestone's range:
- Extend milestone dates — widen the milestone to include the task
- Save as-is — keep the milestone dates unchanged (the task will be flagged as out of range)
- Cancel — go back and adjust the task dates
Containment with relative dates
If the milestone's due date is calculated via "Due Date Relative To" (relative mode), the system can't simply override the dates — the due date is derived from the project reference. In this case, Compass offers adapted options:
- Increase duration to fit — keep relative mode and increase the milestone's duration so the start date expands to cover the tasks. The due date stays locked to the reference. (Only available when the conflict is on the start-date side.)
- Switch to manual dates and adjust — remove the relative reference and set the milestone to manual dates that fit all related tasks. Future reference date changes will no longer update this milestone.
- Keep new dates anyway — save as-is with out-of-range indicators
Visual indicators for out-of-range tasks
Compass provides persistent visual cues so that out-of-range situations don't go unnoticed:
- In the related tasks list: tasks whose dates fall outside the milestone's range show a warning indicator
- On the milestone row in the task table: a warning badge appears when any related tasks are out of range
- In the milestone detail: a warning banner tells you how many related tasks are outside the date range, with a link to the Related Tasks tab
- On the Gantt chart: the portion of a related task that extends beyond the milestone bar is shown in a distinct warning color
An "Expand to fit" action is available on the Related Tasks tab — it adjusts the milestone dates to the smallest range that contains all related tasks.
When containment doesn't apply
If a milestone has no dates set, related tasks can have any dates without warnings. Containment logic only activates when the milestone has at least one date to compare against.
The comparison is always boundary-to-boundary: milestone start vs. task start, milestone due vs. task due. If the milestone only has a due date, only the task's due date is checked — the task's start date is unconstrained.
Automatic recalculation and containment
When a milestone's dates change automatically (because a project reference date changed), no confirmation dialog is shown — the dates move without intervention. But the out-of-range indicators update immediately, so you can spot any newly out-of-range tasks and address them at your convenience.
Standalone milestones
A milestone doesn't need related tasks. A standalone milestone works exactly like a regular task: it has a start date, a due date, and someone accountable for it. The person assigned to it manually marks it complete (or submits a completion request if approval is required).
Standalone milestones are useful when the checkpoint itself is a deliverable — for example, "Signed Contract Received" or "Regulatory Permit Obtained." There's no sub-work to track; the milestone is a binary event that either happens or doesn't.
Milestones as date references
Once a milestone exists on a project, it becomes a reference point for other tasks' due dates. Any task can set its "Due Date Relative To" to Milestone Due Date and select the milestone.
This creates a hierarchy of timing:
- The milestone is timed relative to the project's completion date
- Tasks under the milestone are timed relative to the milestone's due date
Example:
Project Primary Completion Date: January 1
│
▼
"Guest Rooms Ready" Milestone
Due: 30 days before opening = December 2
Duration: 20 days → Start: November 12
│
┌───────┼───────┐
▼ ▼ ▼
FF&E Room Housekeeping
Install Inspect Setup
Due: -20 Due: -5 Due: -10
(from milestone due date)
When the project's opening date shifts, the milestone date shifts, and all tasks relative to the milestone shift with it. The entire sub-tree of work moves coherently.
Nested milestones
Milestones can reference other milestones. A "parent" milestone can have related items, and some of those related items can themselves be milestones, creating a hierarchy.
Example structure:
Project Completion (Primary Target Date)
└── Hotel Opening Ready (Major Milestone)
├── Guest Rooms Ready (Major Milestone)
│ ├── Room 101–200 FF&E Installed
│ ├── All Rooms Inspected
│ └── Housekeeping Inventory Ready
├── F&B Outlets Ready (Major Milestone)
│ ├── Restaurant Equipment Installed
│ ├── Kitchen Health Inspection Passed
│ └── Staff Trained on POS System
└── Technology Ready (Major Milestone)
├── PMS Configured and Tested
├── POS Systems Live
└── Guest WiFi Active
Each sub-milestone is timed relative to the parent milestone's due date, and its tasks are timed relative to its due date. The whole structure cascades from the project's opening date.
How date changes cascade through nested milestones
When a project's reference date changes, the system recalculates dates level by level:
- Milestones that are relative to the project date get their new due dates (and start dates from duration)
- Milestones that are relative to those milestones get recalculated next
- Tasks that are relative to those child milestones get recalculated after that
This cascade continues through the full depth of the hierarchy — there is no depth limit.
For the cascade to work at each level, the "Adjust start and end date if reference date changes" toggle must be enabled. If you turn it off on a child milestone, changes to its parent will not flow through to the child or anything below it.
Containment at each level
Each milestone owns its own containment. A parent milestone checks only its direct related tasks and child milestones — it does not transitively check grandchildren. If a child milestone's dates fall outside the parent's range, the parent shows an out-of-range warning on that child. But the child's own internal containment is checked separately.
Cycle prevention
Compass prevents circular milestone references. You cannot create a chain where Milestone A references Milestone B, and Milestone B references Milestone A (directly or through any number of intermediate milestones). If you try, the system rejects the change.
Progress rollup
Because milestones derive their progress from related tasks, and milestones can be related to parent milestones, progress information rolls up:
- Individual task: manual progress (percent complete) or binary (completed/not)
- Sub-milestone: progress = percentage of its related tasks completed
- Parent milestone: progress = percentage of its related milestones (and/or tasks) completed
This gives leadership a high-level "are we on track?" view at the milestone level, while teams see their individual tasks.
Status, assignees, and dependencies
Auto-controlled status
When a milestone has related tasks, its status is automatically driven by those tasks:
- When any related task is started → the milestone moves to In Progress
- When all related tasks are complete → the milestone moves to Done
The status indicator is read-only in this case — you can't manually override it, because the milestone's status reflects the actual state of its underlying work.
The percent complete slider is also disabled when related tasks exist: progress is calculated, not entered manually.
Assignees: conditional on related tasks
Assignees work differently depending on whether the milestone has related tasks:
| Milestone state | Assignees |
|---|---|
| No related tasks (standalone) | Assignees are allowed — someone needs to be responsible for completing the milestone |
| Has related tasks | Assignees are removed — the related tasks have their own assignees, and the milestone's status is driven by those tasks. Having separate assignees on the milestone would be misleading. |
When you add the first related task to a milestone that has assignees, the assignees are automatically cleared. If you later remove all related tasks, the assignees field becomes available again.
Owners are always available on milestones, regardless of related tasks. The owner is the person who monitors the milestone, not the one who does the work.
Dependencies alongside related tasks
Dependencies and related tasks serve different purposes and can coexist on the same milestone:
- Related tasks = grouping and progress. "These tasks contribute to this milestone's completion."
- Dependencies = scheduling constraints. "This milestone can't start until task X finishes."
A milestone that spans a time period can legitimately depend on another task — for example, "Phase 2 can't start until the vendor contract is signed." Both the Dependencies tab and the Related Tasks tab are visible on milestones.
How milestones affect project health
Compass calculates a project health indicator based on milestones and critical tasks. The health status is either Healthy or Warning.
A project's health switches to Warning when any of the following are overdue (past their due date and not yet completed):
- A Major Milestone
- A task marked as Will Delay Project Completion
Tasks without a due date are ignored — they can't be overdue. Completed tasks and tasks marked as Not Applicable are also excluded, since they no longer represent current risk.
This means that keeping milestones on schedule is directly visible at the project level. When a milestone slips past its due date, the project health indicator immediately reflects it.
Converting a task to a milestone
When you toggle an existing task to become a Major Milestone:
- The existing start date is preserved (not cleared)
- The existing duration is preserved (not cleared)
- The existing "Due Date Relative To" setting is preserved — including "Milestone Due Date" for nested milestone chains
- All date fields remain visible and editable
This means you can convert a task to a milestone without losing any timing information you've already set up.
What happens to subtasks
When you add the first related task to a milestone that has subtasks, the subtasks are removed. Related tasks take over as the mechanism for tracking sub-work — having both subtasks and related tasks would create conflicting progress tracking.
Practical example: Hotel Opening Milestones
A typical "Hotel Opening — Full Service" catalog might include these Major Milestones:
| Milestone | Relative to | Lead time | Duration |
|---|---|---|---|
| Construction Handover | Primary Completion Date | 180 days | 30 days |
| Soft Furnishings & FF&E Complete | Primary Completion Date | 60 days | 45 days |
| Technology Systems Live | Primary Completion Date | 30 days | 20 days |
| Staff Onboarding Complete | Primary Completion Date | 21 days | 60 days |
| Pre-Opening Inspection Passed | Primary Completion Date | 14 days | 7 days |
| Hotel Opens | Primary Completion Date | 0 days | — |
Each milestone has dozens to hundreds of tasks related to it. Project managers see at a glance: "Construction Handover: 72%, on track" or "Technology Systems: 35%, behind schedule."
Milestones with a duration show as bars on the Gantt chart, making it easy to see which phases overlap and how the timeline flows. "Hotel Opens" has no duration — it renders as a diamond, marking the single target date.
Tips for Major Milestones
Keep milestones meaningful: A milestone should represent a real phase gate — something where the business genuinely cares whether it's done. Don't create milestones for every grouping of tasks.
Use milestones as timing anchors: The more you can time tasks relative to milestones (instead of directly to the project's end date), the more flexible and coherent your timeline becomes. Shifting a milestone automatically shifts all its dependent tasks.
Set durations to create planning windows: Give milestones a duration when the phase has a meaningful time span. This creates a visible planning window on the Gantt chart and enables containment checks that warn you when tasks drift outside the expected period.
Assign a clear owner: Every milestone should have one person accountable for reaching it. This person isn't necessarily doing all the work — they're the one tracking it and escalating if things fall behind.
Set "Will Delay Project Completion" carefully: Not every milestone blocks the project — only hard dependencies. A missed "Landscaping Complete" milestone might not block the hotel from opening; a missed "Fire Safety Certificate" absolutely does.
Keep "Adjust dates" on for cascading chains: When you build nested milestone hierarchies (Project → Milestone A → Milestone B → Tasks), make sure "Adjust start and end date if reference date changes" is enabled at every level. If any link in the chain has it turned off, date shifts stop propagating at that point.
Watch the out-of-range indicators: After shifting a milestone's dates or a project's completion date, check for out-of-range warnings on your milestones. These tell you which related tasks no longer fit within the milestone's planning window — so you can decide whether to adjust the milestone, the tasks, or leave them as-is.