Skip to main content

​
Why two concepts?

Older workflow tools often collapse “where you are” and “what you finished” into a single step list. That works until real work gets messy — someone needs to revisit an earlier stage, skip an optional step, or complete achievements in a different order than the template suggests. Tracks split the idea in two: Checkpoint = position. Milestone = achievement at that position.

​
The theme park analogy

Imagine onboarding a new hire:
  • The track is the whole onboarding program.
  • Checkpoints are major areas: Product Knowledge, Shadowing, Compliance.
  • Milestones inside Product Knowledge might be: watched the demo, passed the quiz, shadowed a call.
Your new hire might visit Product Knowledge, move to Shadowing, go back to Product Knowledge for a refresher, then finish Compliance. The suggested route exists, but they are not locked into it.
Screenshot placeholder Track detail → Checkpoints tab. Show the horizontal checkpoint rail with at least three checkpoints. Expand one checkpoint to reveal its nested milestones list.
Video placeholder (Screen Studio) 30–45 second clip: scroll the checkpoint rail, click into one checkpoint, add or view milestones. Communicate that milestones live inside checkpoints, not as a flat list across the whole track.

​
Suggested order vs. actual path

Every checkpoint can have a suggested order — a hint for how work usually flows. That order is guidance, not a prison. On a running instance, people can:
  • Visit checkpoints out of order (when rules allow).
  • Revisit a checkpoint multiple times.
  • Skip optional checkpoints entirely.
The system records each visit and achievement so overseers always know where things stand, even when the path was not straight.
Screenshot or GIF placeholder Instance detail → Checkpoints & Progress tab. Show someone at checkpoint B who previously visited A twice. Visit counts or “last visited” timestamps visible if your UI shows them.

​
Required vs. optional

Not every milestone must be completed for the track to finish. When you design a track, you decide which milestones are required and which are optional extras. Some checkpoints also have requirements — rules that say you cannot enter a stage (or finish the track) until certain milestones elsewhere are done. Think of these as gates, not strict ordering of every step.
Use requirements sparingly. They are powerful for compliance and quality control, but too many gates make the track feel like the rigid SOP you were trying to escape.

​
Examples by entity type

Tracks apply to different kinds of things in your workspace — whatever category you chose when you created the track. The checkpoint/milestone pattern works the same; only the subject changes.
Want examples tailored to your industry?Use the Use Case Brainstorm agent in Evolve — it can help you sketch checkpoints and milestones for your specific business before you build in Tracks.

​
Building checkpoints in the product

When you edit a track, open the Checkpoints tab on the track detail page:
  1. Add a checkpoint and give it a clear name (the stage label overseers will see).
  2. Set its suggested order relative to other checkpoints.
  3. Open the checkpoint and add milestones underneath it.
  4. Configure completion rules for each milestone (covered in Milestones and automation).
Screenshot placeholder Checkpoint detail panel: name, description, suggested order field, and the milestones section with Add milestone visible.

​
Key takeaway

Design tracks by thinking in two layers: where work happens (checkpoints) and what must be true before moving on (milestones). Non-linear flow is a feature, not a bug — it is what makes Tracks a living system instead of a dead checklist. Next: Instances and progress — what happens when you apply a track to a real contact or entity.