What the timeline puts on one axis
The project timeline is not a second plan maintained by hand but a projection over data that already exists. It gathers, in order, four kinds of item: the start of each sprint, its end, the milestones you define and the task due dates. Each item carries its type label and colour, so you can tell at a glance what is a contractual checkpoint and what is internal delivery rhythm. Milestones are created and deleted from the same page, so maintaining the timeline does not mean going through another screen. What the timeline is not: a bar chart with a time scale and drawn durations — it is a vertical list, in date order.
Dependencies: what they do and what they do not
On each task you pick, from a list of the same project's tasks, the ones that block it. The relation is Finish-to-Start — the predecessor must be finished before the successor — and is read from the blocked task, as its "depends on" list; the blocking task does not yet show the list of what it holds up, even though the link is stored in both directions. A task cannot depend on itself, and when a task is deleted its links disappear in both directions, leaving no orphan references. What does not exist: the other three link types (Start-to-Start, Finish-to-Finish, Start-to-Finish), positive or negative lag between them, and automatic recalculation of downstream dates.
Milestones and due dates — how you track them
A milestone is an entity of the project in its own right, with a name, a date and a description, created and deleted from the timeline page; it marks the checkpoint on the axis without gathering tasks underneath it. Due dates sit on the task, are set from its detail panel, and are plain calendar dates, not durations chained to one another. Two project-level indicators rest on them: how many tasks are past their due date and how many fall due in the next seven days, computed from the project data rather than estimated. The same due dates feed the overdue counter on each board column, so the time reference is identical whichever screen you look at it from.
Why there is no critical path here
A critical path requires a duration on each task and a network calculation that sums them along chains. 4myprojects holds due dates and precedence relations, not chained durations, so it computes neither free nor total float, highlights no critical chain, and saves no baseline to measure variance against. The practical consequence: moving a due date stays your decision, taken by looking at the tasks that depend on the one you moved, rather than a cascading reschedule proposed by the platform. There is also no import of plans from other tools and no export of the timeline — the structure is built directly here.
