Timeline, milestones and dates

Two levels: the plan and the calendar

Timing in Sparkus is set up in two places, and it helps to keep them apart.

The program timeline is the plan. It says what checkpoints exist and roughly when they happen relative to the start — “goal setting closes 14 days in”, “the package ends at day 60”. It carries no real calendar dates, because a program can be run many times.
The cohort timeline is the calendar. Each cohort takes the program’s plan and turns it into actual dates for the people in that group — or, for cohorts without a shared calendar, into dates measured from each person’s own start.

The program timeline lives on the program’s Timeline page. The cohort timeline lives on the cohort’s Timeline page.

Milestones come from the journey

Milestones are not typed in by hand one by one. Each enabled item in the program’s journey produces the milestones that make sense for its type:

A package gets a start, an end, and a report-share deadline.
Sessions and matching get a start and an end.
A form, survey, 360-feedback round or session evaluation gets a send date and a deadline.
An assessment, training module, task package or competencies step gets a start and a deadline.
Development goals get a start and a last-feedback date.
A handshake gets a start.

A Program Start milestone always exists and cannot be removed. Regenerating the timeline rebuilds the list from the journey: milestones for newly enabled items appear, and milestones whose item is no longer enabled are switched off rather than deleted, so nothing is silently lost if the item comes back. Hand-added custom milestones survive a regeneration.

You can also add a custom milestone to a program timeline for a checkpoint that doesn’t belong to any item.

What you can set on each program milestone

On the program timeline, each milestone can be given:

A day offset — how many days from the anchor this milestone falls. A negative offset means before the anchor, which is legitimate for windows that open ahead of the start.
A display name, which can be translated per language.
No date at all (marker) — an explicit choice that turns the milestone into a date-less marker on the journey rather than a dated checkpoint.
Show on the participant journey — whether participants see it on their journey strip. Milestones can exist for scheduling purposes without appearing to participants.
Required or optional, and active or inactive.
Order — milestones are dragged into the sequence participants should see.

Changing an offset re-syncs the program’s cohorts so their dates follow the plan. There is also an explicit sync all cohorts action on the program timeline, which pushes the current plan out to every active cohort and reports how many were updated.

Cohort start and end dates

A cohort’s start date and end date are set on the cohort itself, when it is created and from the cohort edit dialog. Both are optional, and that choice is what decides how the cohort’s timing works:

Fixed cohort — both a start date and an end date are set. Everyone shares one calendar.
Rolling cohort — one or both dates are left empty. There is no shared calendar; each person’s dates are measured from their own start date instead.

There is no separate “is this rolling?” switch. Leaving the dates off is the switch.

How a milestone resolves to a real date

Every milestone carries an anchor: the day-zero its offset is counted from.

Cohort start — the default for a fixed cohort. The offset counts from the shared start date, so everyone gets the same date.
Person’s start — the default for a rolling cohort. The offset counts from that individual’s own start date, so day 30 means thirty days after they began.
Previous milestone — the offset counts from the milestone before it in the sequence. This is never applied automatically; it is only ever chosen deliberately.
Set by the step itself — some steps decide their own date upstream (a form’s due date, for example). Where that’s the case, the stored date is the one that counts and is not re-derived.
Fixed date — the stored date is the answer, full stop, with no offset arithmetic.

Offsets are always measured from the anchor, not stacked on top of each other. An offset of 30 means thirty days from day zero — not thirty days after whatever came before it.

When the cohort start date moves

Moving a cohort’s start date shifts its derived milestone dates by the same number of days, so a programme that slips by a week slips as a whole and keeps its internal spacing. Two things are deliberately left alone: milestones an admin has hand-edited, and milestones added directly to the cohort that don’t come from the program plan. Rolling cohorts need no shift at all — their dates are resolved per person at the moment they’re read.

Hand-editing a cohort’s dates

On a cohort timeline you can edit an individual milestone’s date (or its offset), set it to have no date, deactivate it, add a cohort-only milestone, or remove one.

Once you hand-edit a milestone, it is marked as detached from the program plan: later syncs will leave it alone instead of overwriting your edit. If you later want it to follow the program again, re-attach it — the next sync re-derives its date from the plan. Milestones added directly to the cohort stay standalone; they never attach to a program plan.

There is also an option to sync the auto-derived Cohort Start and Cohort End milestones back to the cohort’s dates, and to auto-generate a starter set of milestones on a cohort that has none yet.

Per-person dates

Two mechanisms make a person’s dates differ from the group’s.

Rolling anchoring. In a rolling cohort, everyone’s dates are already personal — resolved from their own start date every time the timeline is read.

Per-person overrides. For any cohort, an admin can pin one milestone to a different date for one person — for sick leave, a delay, a late start. An override is either an absolute date or a re-anchored offset, never both, and it always requires a reason, which is kept on the record with who set it and when. A person can have only one active override per milestone; the override panel on the cohort’s Members area shows every milestone with its group date, any override, and the resulting effective date.

An override wins over everything else when the person’s date is worked out.

People who join after the start

When someone is added to a fixed cohort that has already begun, the admin chooses how their timeline should work:

Personal (recommended) — their still-upcoming deadlines are re-anchored to their join date. Every deadline shifts forward by exactly how late they are, so the spacing of their journey is preserved, and nothing is pushed past the cohort’s end date. Deadlines that had already passed when they joined are left as they are, and informational dates are left alone.
Shared — they inherit the cohort’s dates unchanged. Use this when a deadline genuinely has to bind for everyone at once, such as a feedback window closing on a set day.

This choice has no effect on a rolling cohort (dates are already personal), or when the cohort hasn’t started yet.

Deadlines vs. informational dates

Not every date is a deadline, and the platform treats the two differently.

Deadline milestones move through open → approaching → overdue. These are the real due dates: ends, deadlines, report-share deadlines, last-feedback dates, and the send date of a handshake or session evaluation.
Informational milestones never go red. Start dates, plain send dates and date-less markers are signposts, not obligations.

Two more rules matter in practice:

Completion is a fact, not a guess. A milestone someone has actually completed is done; it is never marked overdue just because a date passed.
A milestone with no date can never be overdue, and for a milestone that spans a range, the deadline is its end, not its start.

Dates are compared as whole calendar days in the reader’s own timezone, so someone near midnight in another region isn’t shown a deadline as missed a day early.

Grace and “approaching” windows

Two tenant-wide defaults tune the ladder above, and are edited on the Timeline Settings system page for the organization currently selected:

Approaching days — how many days ahead of a deadline it starts showing as approaching. Default: 3.
Grace days — the short window after a deadline before it is treated as hard-past. Default: 3.

An individual milestone can carry its own approaching lead time; where it doesn’t, it inherits the organization default.

Checking a timeline before launch

The timeline editor checks the plan for coherence and shows warnings inline. These are warnings, not blocks — you can always proceed. They cover things like:

a cohort or program ending on or before it starts,
a cohort window falling outside its program’s window,
a milestone resolving outside the cohort window,
a milestone ending on or before it starts,
milestones whose order doesn’t match the dates they resolve to,
negative offsets (flagged for confirmation, since a pre-start window is sometimes intended),
reminder lead times that don’t make sense,
milestones with no date.

A cohort’s timeline can be marked as reviewed, recording who reviewed it and which warnings they acknowledged. Any later edit to the timeline marks that review out of date, so the plan has to be looked at again before launch.

Previewing what people will actually see

Because a date on the plan is not a date on a person, both timeline editors let you check the result before anyone is affected:

Pick a cohort and a person to see the timeline as it resolves for them, with their real dates and progress.
Use a sample start date and a “what if today were…” date to see how the plan lands for a hypothetical participant, without touching any data.

This is the fastest way to catch a plan that reads well as offsets but produces a bunched-up or out-of-order calendar in practice.

Terms you’ll see

Term	What it means
Milestone	A named checkpoint in the journey — usually the start, end or deadline of a journey item.
Anchor	The day-zero a milestone’s offset counts from (cohort start, the person’s start, the previous milestone, or a fixed date).
Offset / day offset	How many days from the anchor a milestone falls. Negative means before it.
Fixed cohort	A cohort with both a start and an end date — one shared calendar.
Rolling cohort	A cohort without both dates — each person’s timing runs from their own start.
Marker	A milestone deliberately given no date; it shows on the journey but is never a deadline.
Detached	A cohort milestone that was hand-edited, so program syncs no longer overwrite it.
Override	A per-person date pin on a single milestone, with a required reason.